Further to the 4th OpenPGP Email Summit announcement, this blogpost will provide a brief run-down of our overall experience of the event. We engaged with a number of people behind different OpenPGP based projects, academics and other email security/privacy conscious people. As per the agenda, the 4th OpenPGP summit included plenary talks, open sessions (aka working groups), a key-signing party, food & drinks and of course a lot of fun.
Following is a summary of different points that were discussed during plenary talks and open sessions. Most of the content is very technical and only of interest to those who develop software related to OpenPGP email.
Plenary talks and open sessions of 4th OpenPGP Email Summit (20-10-2018) – Day 1
OpenPGP: Plenary talk
by Phil Zimmermann
– OpenPGP requires a lot of improvements. Let’s make it happen.
– Get rid of the old/obsolete cryptographic primitives and use modern, well-scrutinized and patent-free cryptographic algorithms/design in proceeding versions of the protocol (TLS 1.3 can serve as a good example).
– Chacha20, Poly1305 and AES are just some of the good algorithms (don’t like Galois/Counter Mode though).
– Key verification: OpenPGP trust model is hard to explain to non-technical users. We do fingerprint verification of public keys using different side-channels which are mostly not convenient. Public key fingerprints could be transferred through other secure mediums (e.g., WhatsApp/Signal/…) or ZRTP & Signal protocol (i.e., Silent phone). The idea is to use other mediums/systems on top of OpenPGP to leverage (re-inforce) the trust, instead of the present PGP trust model.
– Lack of network effect in OpenPGP: largely due to operational complexity, we have failed to reach more users. Let us get past that, by taking examples of systems that have already successfully leveraged network effect.
– Looking forward to people who would be interested in improving/modernizing the OpenPGP standard.
Thoughts on integrating Post-quantum Cryptography
– We should start focusing on using Post-quantum cryptography in OpenPGP as well. The time has come.
– Post-quantum keys can be huge, let’s not transport keys but fingerprints instead and download keys from some next-generation key servers.
Moving forward
– Present standard RFC4880; New standard draft RFC4880bis; Working group: https://tools.ietf.org/wg/openpgp/
– Take out old/obsolete cryptographic primitives: ciphers, compression algorithms, …, and other designs choices (e.g., replace MDC with AEAD).
– Get rid of old stuff, trim down as much as possible while fitting the improvement points into existing syntactic framework.
– Use modern day cryptographic primitives (e.g., only ECC-curve25519 based keypairs for new users, …). Drop support for legacy (e.g., remove option to generate old cipher based keys, …) and move in the right direction.
– Ask OpenPGP software providers to keep their implementation up-to-date in user devices (e.g., use some sort of auto-update) and push users to upgrade their keypair by deprecating the old one (if required).
– The OpenPGP universe is a dumpster fire, we need to modernize it. It will take a lot of political will.
Other plenary and informative talks were also given on AutoCrypt, DeltaChat and NextLeap (preventing MITM) projects by respective project owners/members.
OpenPGP session: SKS key servers
Discussion lead: Kristian Fiskerstrand
– Key server pools: https://sks-keyservers.net/overview-of-pools.php
– Covered topics: The new pool requirements, Stripping user IDs for privacy reasons, Improving performance of key server.
– The key server pool currently holds 5 servers run by 2 operators.
– What data should key server hold: Should we store user IDs? Shall we not allow external trust signatures on key servers and use a different service for that? Should SKS only reply to fingerprints?
OR We should make all of that optional?
– Other load balancing issues do exist as well.
– In order to make key servers not willfully ignorant in providing the right key, should we perform the cryptographic operations (e.g., checking trust signatures and making a reasonable decision) or we should drop that function from key server to some external service?
– Alternative implementations (non-OCaml) are welcome too (preferably with minimum requirements).
– Other key discovery mechanisms: WKD (https://wiki.gnupg.org/WKD), Mailvelope key server, etc.
– Want to know community feedback over all this.
For follow-up: Mailing list openpgp@ietf.org (https://www.ietf.org/mailman/listinfo/openpgp)
OpenPGP session: Autocrypt level 2
Discussion lead: Patrick Brunschwig
– Discussion on what to sync (Private key: Autocrypt setup message, Autocrypt state, address book, alternative routing, general preferences of MUA: Signature/HTML/…, rule setting policy, public key ring, filter rules, tags etc).
– Properties: Easy to use, authenticated & confidential, ongoing, automatically, more than two devices, …
– Options to achieve sync: Kolab protocol, pairing mechanism, MLS: group messages protocol, cover message loss.
– Risk/side-effects: End-up syncing to a device you want to sync to (avoid wire tap channel), deleting/duplication, sync fails (deletion of keys, ….), Lateral movement after compromise.
– Separate in multiple Layers: Define mechanism of pairing and sync (how to establish an authentication, channel not the syntax to sync, …), storage (IMAP, NextClout, Gdrive, …), What’s to sync?
– Counter MITM: In-person key verification based on QR code of the public key (automated with authentication tokens), Time-outs in the verification flow (not yet planned, to be discussed), separate keys stored for different contexts (groups vs 1:1), whole key change if any bit changes in the key.
– Autocrypt and Webmail: Integrate Autocrypt (e.g., Mailfence, Mailvelope). Autocrypt doesn’t define techniques for implementation, and mostly leaves that choice to the implementer to go with the best choices under their application architecture.
– Although Autocrypt doesn’t require it, webmail providers sign Autocrypt headers using DKIM to ensure their integrity.
OpenPGP session: Multiple Key Discovery methods
Discussion lead: Daniel Kahn Gillmor
– MUA’s support multiple key discovery methods: How to handle them and how to use different key discovery answers from different location to make a logical/reasonable decision for the right key to be used?
– 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 (via email), Garbage pile by Kai & PEP (via email/keyid/fpr), keybase.io (via username/social media channels/fpr), local override (e.g. local signatures on manually imported keys or the addressbook).
– Confidence on key discovery methods (via email addresses): WKD is being used by GpgOL, Enigmail, … and automatically encrypts messages between two users whose public key is known to WKD.
– Ranking/ordering and collision handling: When services use multiple key discovery methods, and got multiple answers with different public keys? Enigmail and GnuPG have a list with an order in which to look for keys and make reasonable decision on which key to use. Mailvelope key server and garbage pile both only return one result.
– When multiple keys are found: possible actions?
> Ranking – by validity or other criteria like last created sub-key.
> Encrypt to all of them – has the advantage that there is the least danger that the recipient can’t decrypt the message.
> Escalate the problem to the user.
…
– Meta data leakage concerns, each key discovery source has different meta data leakage e.g., DNS is especially problematic, WKD only leaks the domain, …For lookup Start with no meta data leakage and little latency.
OpenPGP session: Representation of digital signature validation message over time
Discussion lead: Daniel Kahn Gillmor
– It’s not clear what a signature means over time, with a store and forward protocol like e-mail. Posed questions: What are the ways that a valid/invalid signature effects my MUA? Looking at old messages, and status now is different, does that effect what my MUA is going to do?
– We don’t seem to have a unified representation of signature validation message over time, in cases when the signer’s key has been expired/revoked after the signature was made.
– OpenPGP.js: Expiration and revocation are treated differently. When a signature is verified, key validity is derived from signature time.
– GnuPG: uses timestamp on the signature itself, if the key was not expired, it is considered valid. Otherwise invalid.
– Different MUAs display signature validation message differently: Require more usability testing and general feedback.
– Using different data points that relate to time, which might be taken into account while evaluating the validity of signature (caching validation results?), and thereby displaying the right signature validation message to the user.
– Signatures and dates are being used in very different ways in different e-mail apps and leaves a room for more conversations and learning from each-other.
OpenPGP session: Protected headers/Memory hole
Discussion lead: Dr.-Ing. Dominik Schürmann
– Specifications were done in 2016, but did not evolve. IETF internet draft is coming up in the following months. A new source with centralized information would be a plus (e.g., a website).
– Some clients do implement it, but there are still implementation (e.g., threading issues with subject, …) and compatibility issues (e.g., fall back mode leading into garbled message, MUA’s not decrypting such messages, …).
– Since the specification is still evolving, a coordination towards stripping the specs down to a minimal level is needed (e.g., starting with encrypting the subject and no references, etc – which would also serve as a good base for proceeding iterations).
– Reduce the search capability: Search within actual subject of the message is not possible.
– Providing advice to MUAs is also needed for different aspects e.g., just use the first MIME part inside the encrypted message, ‘Encrypted subject’ as a subject name also serves as a security indicator: Use “No Subject” or “Subject unavailable” or “Embedded Subject” or “Hidden Subject” – no subject would be disliked by the spam detection measures.
– Privacy consideration: Do not localize the chosen replaced subject string which might reveals the language of the actual message.
The day was ended with a Key signing party!
4th OpenPGP Email Summit Open sessions (21-10-2018) – Day 2
OpenPGP session: Public key servers and GDPR based concerns
Discussion Lead: Patrick Brunschwig & Vincent Breitmoser
– OpenPGP key is PII. Automatically uploading keys without taking user consent in clear and easy-to-understand language (checkbox does not work as they are not that indicative) is making applications GDPR-critical.
– Public key servers haven’t received a complaint so far by a DPA. But we need to move in the right direction.
– People actually use email addresses to find public keys, and it works for people in most cases e.g., Mailvelope key server (but that drops federation and other requirements we have in the pool).
– Idea: Neutral branding of a key server is needed, not use Mailvelope key server in OpenKeychain. Keys.openpgp.org can serve as a home for this new server. Will be managed by small but stable group. Keys should be verifiable and delete-able.
– Points of discussion: Email address, third-party signature, how much of a drop-in-solution do we want? Search by only full-IDs (+ fingerprints) and not sub-strings for performance reasons?
– Interface: HKP? Leave the choice to the key server implementation (or a drop-in replacement), on what data to to return (e.g., all key IDs?). Governance: Ask any non-profit organization to run it? (e.g., EFF)?
– Gmail and some other providers use certain algorithm to clean (removing dots, …) the local part of an email address – which will break the exact match strategy. Could be implemented in lookup tables, or normalize the email representation via some intermediary?
– Looking up using long key-ids (64 bits), can lead to collisions? Later drop long key-IDs, when fingerprints are in signatures.
OpenPGP session: Security indicators (HTML spoofing)
Discussion lead: Daniel Kahn Gillmor
– Viewing HTML leads to several risks: ex-filtration channels? Disable them altogether? Or allow limited viewing of external content?
– Indicators in message list? Populate sender line or other parts that can’t be manipulated by the body? Render emails as text-only, with a button to allow HTML viewing?
– Several clients have issues with single signature state, PGP inline is problematic especially for piecemeal-signed. Perhaps, only have one signature state per message (but that will have an immediate impact on mailing list signatures).
– Limiting cryptographic status to “cryptographic envelope” vs. “cryptographic payload” — only use the set of layers of MIME crypto at the very outside of the message. https://dkg.fifthhorseman.net/blog/e-mail-cryptography.html
– If there’s an inline encrypted blob in a cleartext message, let the user decrypt it manually”?
– University of Bochum sent mail to many MUAs about spoofable UI indicators. We should be prepared to link to that works when complaints come in about simplified display: https://www.golem.de/news/openpgp-gnupg-signaturen-faelschen-mit-html-und-bildern-1809-136738.html
– Space for security headers on interface level is being managed differently by implementations. A lot of improvements can be made, by making sure to educate the user in the most easy-to-understand manner (e.g., showing a detailed indicator by default, but let them minimize the indicator while taking the opportunity to educate them on smaller indicators, …).
OpenPGP session: Timestamping for Signature validation
Discussion Lead: Danny De Cock
– Problem statement: OpenPGP digital signature validation (in most implementations) takes into account the present status (revoked/expired) of the signer’s key, and displays an inaccurate/confusing signature validation message if the signer’s key is revoked/expired.
– Based on the status of signer’s keypair (valid/invalid) when the signature was made (timestamp), if valid – then the digital signature remains valid forever and vice versa in the other case.
– Keep states: Use a trusted third-party to maintain timestamps, and provide signature validation information in case of conflict.
– OR Either use Merkle trees to combine different hash values (using the order of nodes) to verify. E.g., the message receiver can hash every obtained signature and keep a record of it (e.g., in a Merkle tree based database) which can be used as a verifiable medium that can be produced to court.
– In case of signer’s key revocation, there’s always a time between when the key was actually compromised (which could be unknown to the user) and when it was actually revoked by the user. Any signatures made during this time, would be considered as malicious. In case of having a trusted authority, the fall back can be made on the last verified signature (made by the user when the key was not compromised).
– Further to above point, instead of having a trusted authority, we can ask the signer of the message to publish the last verified state of the key on some public channel (e.g., public key servers, other channels, …) which will serve as a datapoint for the last verified state (that can be used to make a reasonable decision e.g., signing time vs last verified state?).
Session slides: https://homes.esat.kuleuven.be/~decockd/slides/20181021.signature.validation.pdf
OpenPGP: Signature validation display
Discussion Lead: Andre Heinecke
– Signature validation display message is different in various implementations.
– The signature validation message also needs to inform the user that a valid signature does not mean that the signer’s key used to sign the message belongs to the rightful owner. There could be a second parameter that makes a statement about the trust in the signer’s key.
– Some implementations also provide sender address verification information aside from the digital signature itself.
– Signatures are made without context, implementations can provide choices e.g., always sign for this recipient with this fingerprint etc.
– A general presentation of the digital signature validation message could be a binary state, if a message is valid or not.
OpenPGP session: Deletable email
Discussion lead: Daniel Kahn Gillmor
– Defining deletable email: control the period of time in which an email can be read.
– An attempt to re-frame “forward secrecy” and adopt it for an archivable message format like email.
– OpenPGP can use sub-keys frequent rotation to achieve the same thing (with a larger time window). But making people repeatedly change keys is a challenge, especially in cases where you can’t read old email, which is mostly not desirable.
– Should emails be archived at all? That is a contradiction to ‘Forward secrecy’. However, many would argue email archival is a feature both in enterprise use-cases (e.g., for compliance reasons) and personal use-cases (e.g., users keep emails by choice).
– Some implementations (e.g., NotMuch) store the session key (symmetrically encrypted), while allowing users to delete/rotate (asymmetric) keys and enabling users to still read old encrypted message. Other approach would be to re-encrypt all messages to a local key.
– There is no self-deletion policy in email clients. Whereas some (instant) messengers do allow that. Other options can be explored too in this regard to state a personal self-deletion policy e.g., in email headers, sub-key annotations, etc. However, enforcing such a policy for emails could require bilateral/mutual bindings agreements.
– Deleting an email locally is not enough, as there’s always other people that could have a copy of that of the message that can be retrieved. Users can simply take a screenshot, or use any other side-channel to keep a copy of that email.
– Some research in this area has proposed using a different sub-key for each message. However, this leads to common issues (e.g., multi-device environments, …).
– Deleting emails after a small window (e.g., a week) or half-yearly would be an improvement in contrast to keeping them for indefinite time?
– Idea: Pre-generate and publish keys for ‘heavy rotation’ enabling communicating parties to use a particular key for for short period of time, and use a different key then. However, frequent rotation might push people to frequently consult key servers, which can lead meta-data (IP, which recipient, …). Requiring out-of-band channel to access rotated keys requires well-connected online medium.
– Talking about small window, emails could take a day to get delivered. We need to figure out what an appropriate time window would be and for whom.
Justus discusses two approaches how to bring 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 wrap-up session, and the day ended with a collaborative/hacking session among different OpenPGP projects with a lot of useful side-talks. A even more detailed version of the sessions with Q/A, can be found here.
We are glad we had the opportunity to host the 4th OpenPGP Email Summit and to gain, share and exchange expertise on important topics which will contribute in shaping up the future of OpenPGP. This also allowed us to engage with other OpenPGP based projects who share with us the common vision of strengthening data security and privacy in this increasingly connected world. We will look forward to further developments on all of the discussed topics in various plenary talks/open-sessions/side-talks and will continue to support any other initiative that contributes in making the Internet a more secure and open place.
Many thanks to:
- Patrick Brunschwig from Enigmail for engaging all the great people together for this summit
- Renewable Freedom Foundation for funding the evening dinners
- All the great and amazing attendees to the 4th OpenPGP Email Summit
Mailfence is a secure and private email-suite that provides users full control over their data. Learn more about us on our press page.
Follow us on twitter/reddit and keep yourself posted at all times.
