Summit 2023 Notes

-- editing in progress --

This page documents the notes that were taken during the 7th OpenPGP Email Summit which took place 2023-05-26/27.

Contents

Plenary talks

Presented performance measurements (time to generate a certificate, time to parse a certificate, time to generate a signature, ...) of different algorithms Dilithium and Kyber: Same order of magnitude as traditional crypto Ed25519 and P256: You can't beat it Sphincs - bad UX: 20 seconds for generating keys, 3 seconds for generating a signature
Size of keys
- Sphincs is huge
- Dilithium and Kyber: same order of magnitude, but larger
Size of signatures
- Much larger than ECC
- Sphincs: 50 kB!
  - Conclusion: may need to rethink how signatures are stored
  - Not good for signing small data
Size of PKESKs
- Reasonably small
Standardization
- Should wait for CFRG to avoid incompatabilities (e.g., byte ordering)
- NIST process is not finished. There is an ongoing 4th round.
- dkg: Conclusion PQC is a moving target and will be for a while.
- Aron: Envisions multiple documents and not one document that contains everything.

Draft shows how to protect headers in an agnostic way (pgp mime and S/MIME) [https://www.ietf.org/archive/id/draft-ietf-lamps-header-protection-15.html](https://www.ietf.org/archive/id/draft-ietf-lamps-header-protection-15.html)
Two mechanisms
- Wrapped messages - what S/MIME specified, but no one did
  - MUAs don't handle this correctly
  - Recommended for parsing
- Injected Headers
  - Recommended for sending
Idea
- When signing a message, the headers usually aren't signed
- Idea: Copy headers into the MIME body (all of them, no exceptions)
- If someone doesn't want to interpret them, it doesn't break anything
- When you interpret the message, there are some wrinkles
- When encrypting, do the same
  - Header confidentiality policy: sender decides what headers should be confidential
  - No reason to not do this today: legacy clients are able to deal with it
Draft is big, because it deals with the wrapped messages, but you can ignore it. Just implement the basic scheme today.

Fetching keys with WKD means many requests
Proton ended up on abuse list
Discovered curl bug, but there is another issue:
Survey of how many serivces offer WKD
- Tons of websites return 200 for any path, so also WKD paths
Direct method is spam-prone (no possibility to fail on DNS level)
Not limited to direct method
Wildcard DNS + Wildcard Certs are an issue
Workaround: Look up WKD domain, also lookup https://openpgpkey.example.com/.well-known/openpgpkey/example.com/policyfailure and check if second one fails

What is the WKD implementation doing
Logged what domains have WKD support to see what was going on
Expecting a few logs per day or hour
Result: very noisy
A lot of them clearly don't have WKD, a few were legit
Many websites return 200 for anything(!)
If a website returns 200 for policy document, then we start using it for WKD requests
More common with direct method, but the advanced method also had a lot of false positives
- Lots of websites have wildcard domains and route all subdomains to the main website
Solution:
- Lookup the correct policy string and policy string + "policy-failure"
- If the first succeeds and the second fails, then we're good
- Otherwise, assume that it returns 200 for anything
- Works great: reduces key fetches, and abuse score reduced a bit
- Logging for 10 days: observed 242 advanced WKD installations (not including Proton's), 167 direct WKD installations
Conclusion
- direct method is more prone to this
- would recommend dropping direct method
dkg: We could go the way of MTA-STS and require a TXT record.
- If we require a new subdomain, then adding a TXT record too is not too big of an additional ask