|
⇤ ← Revision 1 as of 2023-05-28 23:04:15
Size: 19
Comment:
|
Size: 4347
Comment:
|
| Deletions are marked like this. | Additions are marked like this. |
| Line 1: | Line 1: |
| Summit 2023 Notes | = 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. <<TableOfContents(3)>> == 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 |
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
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
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
- 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