IETF-116 OpenPGP WG Meeting

Wed, March 29, 1530-1700 local (Asia/Tokyo), 0600-0800 UTC

Notetaker: Jonathan Hammell

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)

• 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)

• 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)

• 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)

• 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

• Stephen: Any objection to submitting draft -09 for publication in
  the next couple weeks after the MRs are merged?
• no objections raised

Interoperability

Stateless OpenPGP CLI update (Daniel Khan Gillmor)

• profile option for generate-key and encrypt

Interop test suite update (Justus Winter)

• Stephen: Thanks for all that interop work.

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

• 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.