= Summit 2023 Notes = **-- editing in progress --** This page documents the notes that were taken during the [[OpenPGPEmailSummit202305|7th OpenPGP Email Summit]] which took place 2023-05-26/27. <> == Plenary talks == === Post Quantum - Aron === * 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. === Header Protection for Cryptographically Protected E-Mail - dkg === * 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.    === WKD and Abuse Reports === * 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 === Learning from WKD at scale - Bart === * 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