Le 4e OpenPGP Email Summit organisé par Mailfence : Un bref aperçu !
Following the announcement of our 4th OpenPGP Email Summit , this article will provide a brief overview of this event. We have collaborated with a number of people involved in various OpenPGP projects, academics and others concerned with email / privacy security. The agenda for this 4th OpenPGP Email Summit included plenary discussions, public meetings (ie, working groups), a key signature party, food and beverages, and of course, a lot of fun.
The following is a summary of the various points that were discussed in plenary and public meetings. Most of the content is very technical and only interested OpenPGP email software developers.
Plenary sessions and public meetings of the 4th OpenPGP Email Summit (20/10/2018) – Day 1
OpenPGP: conference in plenary session
of Phil Zimmermann
– OpenPGP requires a lot of improvements. Let’s work on these improvements.
– Get rid of old and obsolete cryptographic primitive versions of the protocol, and use modern, well-researched and patent-free cryptographic algorithms and designs when you use the protocol (TLS 1.3 can be one of them good example).
– Chacha20, Poly1305 and AES are just some of the good algorithms (they do not like the Galois / Counter mode, though).
– Key verification: The OpenPGP trust model is difficult to explain to non-technical users. We check the fingerprints of public keys using different side channels, which is usually not practical. Fingerprints of public keys can be transferred via other secure media (for example, WhatsApp / Signal / …) or the ZRTP & Signal protocol (for example, Silent phone). The idea is to use other media / systems in addition to OpenPGP to leverage (strengthen) trust, instead of PGP’s current trust model.
– Lack of network effect in OpenPGP: due in large part to operational complexity, we have not been able to reach more users. Exceed that by taking examples of systems that have already successfully exploited the network effect.
– We look forward to the people who will have the ambition to improve / modernize the OpenPGP standard.
Reflections on the integration of post-quantum cryptography
– We should also start using post-quantum cryptography in OpenPGP. The time has come.
– Post-quantum keys can be huge. Do not ship keys, but rather fingerprints, and download keys from next-generation key servers.
– Current standard RFC4880; New draft RFC4880bis standard; Workgroup: https://tools.ietf.org/wg/openpgp/
– Delete old / obsolete cryptographic primitives: ciphers, compression algorithms, …, and other design choices (eg, replace MDC with AEAD).
– Eliminate obsolete elements, reduce as much as possible while integrating the points of improvement into the existing syntactic framework.
– Use modern cryptographic primitives (for example, only ECC-curve25519-based key pairs for new users, …). Remove support for the old one (for example, remove the option to generate old keys based on encryption, …) and move in the right direction.
– Ask OpenPGP software vendors to keep their implementation up-to-date in users’ devices (for example, use some kind of automatic update) and prompt users to update their key pair by deleting the old key ( if necessary).
– The OpenPGP universe has not been well managed, we need to modernize it. It will require a lot of political will.
Other informative presentations were also presented on the AutoCrypt, DeltaChat and NextLeap projects (to prevent MITM attacks) by their respective owners / members.
OpenPGP Session: SKS Key Servers
Discussion moderated by: Kristian Fiskerstrand
– Key server pools: https://sks-keyservers.net/overview-of-pools.php
– Topics covered: New pool requirements, Removing user IDs for privacy reasons, Improving server performance of keys.
– The keystore pool currently contains 5 servers managed by 2 operators.
– What data should the key server contain? Should the user IDs be stored? Should we not allow external trust signatures on key servers and use a different service for this? Does SKS only have to respond to fingerprints?
OR should we make all this optional?
– There are other load balancing issues as well.
– To avoid making key servers deliberately ignorant to provide the correct key, do we need to perform cryptographic operations (for example, verify trusted signatures and make a reasonable decision) or give up the server de keys manages this function to entrust it to an external service?
– Alternative implementations (non-OCaml) are also welcome (preferably with minimal requirements).
– Other key discovery mechanisms: WKD (https://wiki.gnupg.org/WKD), Mailvelope key server, etc.
– You want to know the reactions of the community on this subject.
For tracking: Mailing list firstname.lastname@example.org (https://www.ietf.org/mailman/listinfo/openpgp)
OpenPGP Session: Autocrypt level 2
Discussion moderated by: Patrick Brunschwig
– Discussion of the elements to be synchronized (private key: automatic encryption configuration message, automatic encryption status, address book, alternative routing, general mail client preferences: signature / HTML / …, policy definition policy, public key set, filter rules, tags, etc.).
– Properties: Easy to use, authenticated & confidential, in progress, automatically, more than two devices, …
– Options to achieve synchronization: Kolab protocol, matching mechanism, inter-agency services: group message protocol, message loss blanket.
– Risk / side effects: lead to synchronization to a device with which one wishes to synchronize (avoid wired access), deletion / duplication, failure of synchronization (deletion of keys, ….), Lateral movement after compromise.
– Separate in several layers: define the mechanism of pairing and synchronization (how to establish an authentication, not to channel the syntax to be synchronized, …), the storage (IMAP, NextClout, Gdrive, …), What must be synchronized?
– MITM counter: key verification in person based on the QR code of the public key (automated with authentication tokens), downtime in the verification flow (not yet scheduled, to be discussed), separate keys stored for different contexts (groups or .1: 1), the whole key must change if an element of the key is changed.
– Automatic encryption and Webmail: Integrate Autocrypt (for example, Mailfence, Mailvelope). Autocrypt does not define implementation techniques and usually leaves that choice to the performer to make the best choices in their application architecture.
– Although Autocrypt does not require it, webmail providers sign Autocrypt headers using DKIM authentication technology to ensure their integrity.
OpenPGP Session: Multiple Key Discovery Methods
Discussion moderated by: Daniel Kahn Gillmor
– MUA (Mail User Agent) discovery methods: how to handle them and how to use different key discovery responses from different locations to make a logical / reasonable decision as for the use of the correct key?
– Existing key discovery methods: Autocrypt (via email), WKD (via email), SKS pool (via email / keyid / fpr), Mailvelope key server (via email / keyid / fpr), LDAP (via email / keyid / fpr), DNS (by email), Garbage Stack by Kai & PEP (via email / keyid / fpr), keybase.io (by username / or through social media / fpr ), local replacement (for example, by local signatures on keys imported manually or in the address book).
– Confidence in key discovery methods (via email addresses): WKD is used by GpgOL, Enigmail, … and automatically encrypts messages between two users whose public key is known to WKD.
– Ranking / ranking and conflict management: when services use multiple key discovery methods and get multiple answers with different public keys? Enigmail and GnuPG have a list with an order in which keys can be searched for, making a reasonable decision as to which key to use. The Mailvelope and garbage stack key server both return only one result.
– When several keys are found: what are the possible actions?
> The ranking – based on validity or other criteria like the last subkey created.
> Encryption using each of them – has the advantage that the risks that the recipient can not decrypt the message are minimized.
> Send the problem to the user.
– Metadata leakage problems, each source of key discovery having different metadata leaks, for example, the DNS is particularly problematic, the WKD only reveals the domain, … For the search, start without metadata leaks and with low latency
OpenPGP Session: Representation of the validation message of the digital signature in time
Facilitator of the discussion: Daniel Kahn Gillmor
– The meaning of a signature over time is unclear, with a storage and transfer protocol such as email. Questions: How does a valid / invalid signature affect my MUA? By examining the old messages, knowing that the status is now different, does this affect what my MUA will do?
– We do not seem to have a unified representation of the signature validation message over time, in cases where the signer’s key has expired or been revoked after signing.
– OpenPGP.js: expiration and revocation are treated differently. When a signature is verified, the validity of the key is deduced from the time of the signature.
– GnuPG: uses the timestamp on the signature itself. If the key has not expired, it is considered valid. Otherwise it is considered invalid.
– The different MUAs display the signature validation message differently: require more usability tests and general comments.
– Use different data points related to time, which could be taken into account when evaluating the validity of the signature (caching validation results?), And thus display the correct validation message of the signature to the user.
– Signatures and dates are used in very different ways in different email applications and give way to more conversations and mutual learning.
OpenPGP Session: Protected Headers / Memory Hole
Discussion moderated by: Dr.-Ing. Dominik Schürmann
– The specifications were determined in 2016, but have not changed. The draft Internet standard IETF is expected to arrive in the coming months. A new source of centralized information would be an advantage (for example, a website).
– Some clients implement it, but there are still implementation problems (for example, threading problems with the subject, …) and compatibility (for example, the fallback mode leading to a truncated message, the MUA decrypting no such messages, …).
– Since specifications are still evolving, coordination to minimize the specifications is necessary (eg, by starting to encrypt the subject and avoiding references, etc., which would also be a good basis for proceeding with iterations).
– To reduce the capacity of research: the research in the real object of the message is not possible.
– It is also necessary to advise MUAs for different aspects, for example, to use only the first MIME part of the encrypted message, « Encrypted Subject » as subject name also serves as a security indicator: Use « No Subject » or « Subject unavailable » or « Embedded Subject » or « Hidden Subject » – « No Subject » would be rejected by the spam detection measures.
– Privacy Consideration: Do not locate the chosen replaced subject string that might reveal the language of the actual message.
The day ended with a key signing party!
4th OpenPGP Email Summit public sessions (21-10-2018) – Day 2
OpenPGP Session: Public Key Servers and
GDPR- Based Issues
Discussion moderated by: Patrick Brunschwig & Vincent Breitmoser
– The OpenPGP key is PII. The automatic key download without the user’s prior consent in a clear and easy-to-understand language (the checkbox does not work because it is not very indicative) makes the applications critical for the GDPR.
– At this time, public key servers have not received any complaints from a Data Protection Authority (PDA). But we must go in the right direction.
– People actually use email addresses to find public keys, and it works in most cases, for example, the Mailvelope key server (but this removes the federation and other requirements we have in the pool).
– Idea: the neutral mark of a key server is necessary. Do not use the Mailvelope key server in OpenKeychain. Keys.openpgp.org can serve as a host for this new server. It will be managed by a small but stable group. The keys must be verifiable and removable.
– Discussion points: e-mail address, third party signature, which alternative solution do we want? Search only with full IDs (+ fingerprints) and not with substrings for performance reasons?
– Interface: HKP? Leave the choice to the implementation of the key server (or an instant replacement), which data to return (for example, all key IDs?). Governance: ask any non-profit organization to run it? (for example,
– Gmail and some other providers use some algorithms to clean (delete points, …) the local part of an e-mail address – which will interrupt the exact matching strategy. Could this be implemented in search tables, or could the representation of the email be standardized by means of an intermediary?
– Can searching with long (64-bit) key identifiers cause conflicts? Later, delete long key identifiers, when fingerprints are in the signatures.
OpenPGP Session: Security Indicators (HTML Spoofing)
Discussion moderated by: Daniel Kahn Gillmor
– The HTML display entails several risks: ex-filtration channels? Disable them completely? Or allow limited viewing of external content?
– Indicators in the message list? Fill the sending line or other items that can not be handled by the body text? Restore emails as text only, with a button to allow HTML display?
– Several customers have problems with only one signature state, PGP inline is problematic, especially for piece-by-piece signatures. Maybe only have one signature state per message (but this will have an immediate impact on mailing list signatures).
– Limit cryptographic status to « cryptographic envelope » against « cryptographic payload » – use only the set of layers of the MIME crypto at the very periphery of the message. https://dkg.fifthhorseman.net/blog/e-mail-cryptography.html
– If there is an encrypted online blob in a plain text message, let the user manually decrypt it?
– The University of Bochum has sent a mail to many MUAs about UI indicators that can be spoofed. We should be prepared to link with its work when complaints about a simplified posting occur: https://www.golem.de/news/openpgp-gnupg-signaturen-faelschen-mit-html-und-bildern-1809 -136738.html
– The space for the security headers at the interface level is handled differently by the implementations. Many improvements can be made, making sure to inform the user in the easiest way to understand (for example, by displaying a detailed default indicator, but allowing the indicator to be reduced while taking the opportunity to inform him about the smallest indicators, …)
OpenPGP Session: Timestamp for Signing Validation
Discussion moderated by: Danny De Cock
– Problem statement: OpenPGP digital signature validation (in most implementations) takes into account the current (revoked / expired) status of the signer’s key and displays an imprecise / confusing signature validation message if the key the signatory is revoked / expired.
– Given the status of the signer’s key pair (valid / invalid) at the time of the signature (timestamp), if it is valid – the digital signature remains valid forever and vice versa in the other case.
– Keep reports: Use a trusted third party to manage timestamps and provide signature validation information in case of conflict.
– OR Use the Merkle trees to combine different hash values (using the order of the nodes) to check. For example, the recipient of the message may hash each signature obtained and keep a record (in a database based on a Merkle tree for example), which can be used as a verifiable support that can be sent to the court.
– If the signer’s key is revoked, there is always a delay between the time the key has been compromised (which may be unknown to the user) and the time it was revoked by the user. Any signature made during this time would be considered malicious. If a trusted authority is present, the last verified signature (done by the user when the key has not been compromised) can be used.
– In addition to the above, instead of having a trusted authority, we can ask the signer of the message to publish the last verified state of the key on a public channel (eg, public key servers, other channels , …), which will serve as the data point for the last verified state (which can be used to make a reasonable decision, for example, the signature time relative to the last verified state?).
Slides of the session: https://homes.esat.kuleuven.be/~decockd/slides/20181021.signature.validation.pdf
OpenPGP: Signature Validation Display
Discussion moderated by: Andre Heinecke
– The signature validation display message is different for different implementations.
– The signature validation message must also inform the user that a valid signature does not mean that the signer’s key used to sign the message belongs to the legitimate owner. There could be a second parameter giving an indication of trust in the signer’s key.
– Some implementations also provide information for verification of the sender’s address in addition to the digital signature itself.
– Signatures are made without context, implementations can provide choices, for example, always sign for this recipient with this fingerprint, etc.
– A general presentation of the digital signature validation message could be a binary state, whether a message is valid or not.
OpenPGP Session: Deletable E-mail
Discussion moderated by: Daniel Kahn Gillmor
– Definition of the deletable email: controls the period of time during which an email can be read.
– An attempt to reframe the « transmission secret » and adopt it for an archival message format such as email.
– OpenPGP can use a frequent rotation of the subkeys to obtain the same result (with a longer time window). But it is difficult to change keys several times, especially in cases where you can not read old emails, which is generally not desirable.
– Should emails be archived? It is a contradiction with the « secret of transmission ». However, many believe that email archiving is a feature in corporate use cases (for example, for compliance reasons) and in personal use cases (eg users can keep their e-mails by choice).
– Some implementations (for example, NotMuch) store the session key (symmetrically encrypted), while allowing users to delete / rotate keys (unbalanced) and allowing them to read the old encrypted message. Another approach would be to re-encrypt all messages on a local key.
– There is no self-deleting rule in email clients. While some (instant) messengers allow it. In this regard, other options can also be explored to define a personal deletion policy, for example in email headers, subkey annotations, and so on. However, the application of such a policy for e-mails may require bilateral / mutual reconciliation agreements.
– Deleting an e-mail locally is not enough, because there are always other people who could have a copy of the message that can be retrieved. Users can simply take a screenshot or use another side channel to keep a copy of this email.
– Some research in this area suggested using a different subkey for each message. However, this leads to common problems (for example, multi-device environments, …).
– Would deleting e-mails after a short time (for example, a week) or every six months be an improvement over their retention for an indefinite period?
– Idea: pre-generate and publish keys for an « intensive rotation » allowing the parties in communication to use a particular key for a short time, then to use a different key. However, a frequent rotation can push users to frequently consult key servers, which can lead to metadata (IP, which recipient, …). Requiring an out-of-band channel to access the rotated keys requires well-connected online support.
– Regarding intervention windows, emails can take a day for their reception. We need to determine what turnaround time would be appropriate, and for whom.
Justus discusses two approaches to how to adapt Forward Secrecy to OpenPGP: https://sequoia-pgp.org/talks/2018-08-moving-forward/moving-forward.pdf https://www.youtube.com/ watch? v = an6oYjikAPY
The working groups were followed by a synthesis session and the day ended with a collaborative / hacking session between various OpenPGP projects with many good parallel discussions. You will find here (link in English) an even more detailed version of these sessions with a FAQ.
We are pleased to have had the opportunity to host the 4th OpenPGP Email Summit and to acquire, share and exchange skills on important topics that will shape the future of OpenPGP. It has also allowed us to collaborate with other OpenPGP projects that share with us the shared vision of strengthening data security and privacy in this increasingly connected world. We look forward to further developments on all the topics discussed at various plenary / open / parallel discussions and will continue to support any other initiative to make the Internet a safer and more open place.
We warmly thank you especially:
- Patrick Brunschwig of Enigmail for having involved all these great people on the occasion of this summit
- The Renewable Freedom Foundation for Dinners Funding
- All outstanding participants of the 4th OpenPGP Email Summit
Join the fight for online privacy and digital freedom .