# IETF-116 OpenPGP WG Meeting {#ietf-116-openpgp-wg-meeting} Wed, March 29, 1530-1700 local (Asia/Tokyo), 0600-0800 UTC Notetaker: Jonathan Hammell ## Agenda Bash {#agenda-bash} * no bashing * Stephen Farrell (chair): plan is that after this meeting, there will be another revision of the crypto-refresh draft, then go for publication ## Crypto-refresh issues (Daniel Khan Gillmor) {#crypto-refresh-issues-daniel-khan-gillmor} * outline of changes since draft -07 * a couple changes in the git repo since draft -08 ### New algorithm IDs for the CFRG algorithms in OpenPGP (Daniel Huigens) {#new-algorithm-ids-for-the-cfrg-algorithms-in-openpgp-daniel-huigens} * OpenPGP used weird OIDs for Curve25519 * recent interest on switching to the X.509 OIDs * using new algorithm IDs instead to take the opportunity to clean up the usage of Curve25519 in OpenPGP * No MPIs (native encoding on the wire), no checksum (AES-KW already has one), and no padding (for v6 PKESK) * draft -08 uses an ad hoc padding scheme to work with v3 PKESK (which includes the symmetric algorithm ID in the session key) * the version on git instead leaves the symmetric algorithm ID unencrypted, since hiding it doesn't add much * leaving it unencrypted could lead to cross-algorithm attacks * mandate use of AES? * need the Intended Recipient Fingerprint signature subpacket to bind the recipient fingerprint * Stephen: what is the state of this? In a MR? * Daniel: Most of it is in git, will make a MR for mandating AES if everyone agrees * Stephen: What do you mean by mandating use of AES * Daniel: If you are encrypting to multiple keys (one of these new one and a legacy one), then you have to leave the symmetric alg ID unencrypted. But then someone could change the symmetric alg ID. So we mandate the use of AES, so an implementation can reject messages encrypted with another algorithm * DKG: if you are encrypting to a new key with an old style of encryption, then you should use AES as the symmetric cipher to avoid the potential of a cross protocol attack. * DKG: Daniel, will you put a MR and send to the Mailing List. * Daniel: Will do. * Joris Baum: Wouldn't this mean to cover the corner-case is to require AES always? * Daniel: Question is whether we mandate it always or only in the corner-case. Implementations have a choice. * Falko Strenke: The corner-case is unlikely. * Daniel: I agree. * DKG: If you are in the niche corner-case, you likely want to use AES anyway. * DKG: Make the MR as minimal and clear as possible. * Stavros Kousidis: The key derivation just takes the shared key, it doesn't take the ephemeral point? There is an option in the RFC for parties to use the ephemeral components in the KDF. * Daniel: We just are using the shared key. * DKG: Should the current implementation change? * Stavros: From my point of view, yes. But I don't want to delay the process. The change shouldn't be heavy. The reason behind it is the HKDF is CCA-secure. Noted in the RFC that specifies the X-algs. * Daniel: If we have the intended recipient fingerprints in the signature, do you get the same properties? * Stavros: Not sure. * Daniel: There is a downside of doing this to automatic forwarding. * Aron Wussler: It boils down to whether you want CCA2 security. Maybe relevant for a smartcard use case, but for more cases it is not. * Stephen: This is a change we could do, but it would add another couple of weeks for discussion. Is anyone really pressing for this change now? * Stavros: I'm not pushing on this. * Roman: The WG cannot recharter until the refresh is done. * DKG: If the change is made, would anyone object? * Aron: I would be happier without it, due to impact to forwarding and the delay. * Stephen: I think that the it seems we should not do this change. But anyone who strongly believes in it should comment on the mailing list. * Daniel will make a MR (not including changing the KDF inputs) and post to the mailing list. ### Outstanding Merge Requests (dkg) {#outstanding-merge-requests-dkg} * MR !268 (Subpacket Criticality) * MR !269 (Primary Keys MUST be able to sign) * MR !271 (SHOULD implement subpackets) * MR !272 (Clarify self-sig guidance) * MR !273 (Clean up Notation registries) * MR !228 (Session Key Reuse) - more later * MRs for test vectors * MR !223 (Remove checksum+padding from v6 ECDH) * maybe not needed with CFRG curves * Stephen: clarification, will this MR be dropped? * DKG: yes * DKG: merging it will make a wire format change * no objection ### Security Considerations for Session Key Reuse (Falko Strenzke) {#security-considerations-for-session-key-reuse-falko-strenzke} * session key reuse (SKR) mechanism allows reply using only symmetric encryption with key derived with a new salt * pitfall 1: replying to only a subset of the original recipients * pitfall 1a: special case where attacker removes themselves from the recipient list * pitfall 2: replying to more than the original recipients * pitfall 2a: save the message, then add more recipients * pitfall 3: interfering session key reuse * interoperability can be a problem between clients that have differing support * Security Considerations section documents these pitfalls and provides SKR guidance * Stephen: Where is this? Merged? * DKG: In a MR, but not merged yet * no objections * Stephen: MR should be merged ### Next Steps {#next-steps} * Stephen: Any objection to submitting draft -09 for publication in the next couple weeks after the MRs are merged? * no objections raised ## Interoperability {#interoperability} ### Stateless OpenPGP CLI update (Daniel Khan Gillmor) {#stateless-openpgp-cli-update-daniel-khan-gillmor} * profile option for generate-key and encrypt ### Interop test suite update (Justus Winter) {#interop-test-suite-update-justus-winter} * Stephen: Thanks for all that interop work. ## Re-chartering topics {#re-chartering-topics} * Stephen: topics came from mailing list, email to chairs, and gitlab * Stephen: Join the queue if anyone has opinions on what is your top two topics ### Summary of various topics {#summary-of-various-topics} * PQC (Falko Strenzke) * Automatic Forwarding (Aron Wussler) * Key Superseded (Aron Wussler) * Replacement for Designated Revoker (dkg) * User ID clarifications (dkg) * Attestation Signatures, a.k.a. "1PA3PC" (dkg) * WoT: Trust Signatures, Regex subpackets, Validation constraints, Certification capable subkeys (dkg) * Stateless OpenPGP Interface ("SOP") (dkg) * Reusing session keys in a specific application layer: E-mail Messages * PGP/MIME guidance for v6 signatures * Various (Daniel Huigens) * Long-term symmetric keys (Daniel presented on at IETF 114) * Forward secrecy (possibly mostly covered by short-term keys + re-encryption using long-term symmetric keys, but might still be worth discussing separately, to see if we want a more "proper" solution like double ratcheting) * Domain separation * Key verification, e.g. a better alternative to manually verifying fingerprints. This topic could include using QR codes or similar, or even something like Key Transparency to automatically verify keys (which Aron presented on at IETF 113). * Daniel: I agree PQC should be the top priority. Automatic forwarding is also important and interesting. Long-term symmetric keys would be useful for encrypting data only for yourself. Long-term symmetric keys is the most important in my topics. Domain separation should be easy. Forward secrecy has been an issue for a while. * Stephen: It seems there is consensus to do PQC. So no need to indicate it. * Justus Winter: We want a way to share certificates and trust roots between implementations. * Stephen: Is there an existing issue with this. * Justus: We started writing a draft on this and happy to bring it in. * Justus: Would like see semantics for issuing certificates harmonized. * DKG: Is there a draft? It would be easier to discuss. * Justus: I don't think it has been written down. * Justus will create an issue in gitlab. * Stephen: Is it wrong to suggest that this list (with Justus's additions) is a superset of what we want to do? * no objects * Stephen: Most topics are concrete, except for fingerprints. * Aron Wussler: Also for key superseded, we have proposed one way but there are other options. * DKG: Is WKD something you would like to consider? * Aron: On would like to see it, but not volunteer for it. * Roman: The KeyTrans BoF seemed to have general agreement and interest in doing work. Will result in producing a charter. Nothing jumps out as overlap. * Roman: I think OpenPGP should move forward and not lose the momentum. * Justus: Representation of trust semantics could be another topic. * Aron: What we produce should be aligned with KeyTrans. So we may need to wait until they proceed. * Daniel: WKD is mostly done since it is being used. But may be valuable to have as a formal RFC. * Stephen: Will schedule a virtual interim to discuss chartering topics after the crypto-refresh is submitted. * DKG: Gitlab admin repo has existing charter. * Stephen: Consider the topics in the meantime. * DKG: Clearest way to demonstrate interest is to write an individual draft on the topic. * Roman: I want to applaud the WG on getting to the finish line.