OpenPGP @ IETF 119

Meeting: Wed 20th March, 0930-1130 (local)
Notes: Rich S, Mike O

No changes to agenda.

Draft 13 did not make any substantive changes. It is in the RFC Editor's
queue.

We have a badge! Should show up on the IETF badges page soon.

Working has been rechartered.

PQC Aron Wussler

KEM selection

Current proposal is MLKEM+25519 as a MUST, MLKEM+X448 is a SHOULD. Any
interest in working on a NIST curve draft? Yes there is interest.

Mike O: No pure-PQ solution proposed?

Aron: Yes, that's the consensus of the WG so far.

Stephen: the codepoint space for algorithms is 8bits, so we want to
proceed carefully. Other WGs have a much larger space (TLS, LAMPS, etc)

Mike: We agree on the "X" curves, so I'm in favor of splitting so as to
not slow things down.

Quynh: If we split, and I am a co-author on NIST hybrid, I would start
by adding MLKEM512.

Stavros: if we split and then recombine later, that just feels like
make-work. if we split, let's just go ahead and publish the drafts
separately.

KEM Combiners

Quynh: for FIPS validation, the way you use KMAC would likely be
compliant, but using only SHA3 might not be compliant because we
currently only allow SHA-3 used within the SP 800-56Cr2 construction,
not by itself like this.

Aron: but this construction includes the counter so that it is
attempting to be exactly the SP 800-56Cr2 construction.

Justus: Would like one key combiner rather than multiple. (in chat,
Justus offered to contribute text to the draft explicitly encouraging
reuse of the combiner mechanism by other hybrid encryption schemes)

Stephen: should we have one? Probably consensus. Should they match other
WGs?

Mike: Put a note in the draft that says "this may change when CFRG
figures things out"

Mike Gray: In favor of having one that could be re-used implementations
and data structures.

Quynh: Just looked at the requirements from NIST, proposed construct
meets them.

Stephen: nobody seems to object, move forward, let's do interop testing,
and keep the CFRG work in mind while doing that especially if it's used
by other work within the IETF.

Signatures

Stephen: focus on teasing out the arguments, since we don't get to
consensus here and now; doing that will need an interim.

(See the slides for proposal details.)

Quynh: I am willing to co-author a NIST curve signature draft.

Mike O: See the jabber room as there is a healthy discussion going
there.

Stavros: question about how many separate, versus combined, drafts do we
want?

Stephen: Whatever the authors want to do in terms of drafts.

Aron: Please bring up the jabber topics on the list.

Scott: If we do two signatures, are they both signing the hash, or what?

Aron: PGP has a hash-then-sign model, and the signing includes the
identifier for the algorithm and other key metadata, so it's not just
one hash both sign. In the proposed composites, the composite signature
is one hash, both sign. When there are two OpenPGP signatures, they do
not sign the same bytestream

Daniel Huigens: Three SLH-DSA options seems like a lot.

Aron: Authors are keen to have them, there is a significant size
difference.

Other discussion about size and trade-offs. Will not be decided here.

Mike O: I know Andreas has clear ideas on when each algorithm is
appropriate. Could you get that added to the draft please? Might help us
figure out whether these differences are significant to implementers and
end-users; if we can't describe it succinctly, then maybe that indicates
that three options are not needed.

Falko (in chat): I think this set is already quite restricted for an
algorithm with such challenging performance characteristics.
time-memory-tradeoffs are really important in this case

Stephen: Option 2 has no supporters, authors prefer Option 3. (Stephen
prefers Option 1). Seems WG wants to get experience with Option 3,
right? (No disagreements in the room.)

Stephen: A poll on being in favor of all the modified proposals? 16 yes,
9 no opinion. To be confirmed on the list but we have a likely path
forward.

Migration/interoperability (e.g. PQ v4/v6), Justus

Currently, PQ signatures are bound to v6 keys, but PQ encryption is not
bound to v6 keys. Rationale is that we don't want to impede the adoption
of PQ. Proposal to make PQ encryption only allowed with v6 keys; it
gives a reason to move and putting PQ encrypt subkeys to v4 certificates
isn't feasible.

Rich Salz: drawing a parallel with the TLS WG; TLS decided to not
support PQ in TLS 1.2 and let this be a forcing function to move
adoption to 1.3.

Aron: Since OpenPGP is not negotiated live, it's not an entirely apt
comparison.

Rich: My point the TLS WG saw it more as a forcing function to get
implementations upgraded.

DKG: we have a risk here of introducing a novel failure mode here where
I could invidually encrypt for UserA on a Tradational key, and to UserB
on a PQ key, but I cannot encrypt to them both together. This is maybe
the correct behaviour, but it is a novel failure mode and we should be
careful about introducing it.

Aron: We should figure out how to make this work and not fail. The path
forward is essentially to use "v4 style" (SEIPDv1) encryption for when
using a combination of v4 and v6 keys. Also with a warning on the sender
(and maybe also receiver).

DKG: what should a client do if it encounters an illegal PQ signature or
encryption key in a v4 packet?

Aron: if it's a MUST then it should be treated as a key that the client
doesn't understand.

Paul Wouters: What about v5? Should we say "not v4"

Aron: Please don't put PQ in v5, they already did something completely
different from what we are defining.

Paul: I'm saying we should say nothing about v4 and be silent about v5,
avoid it. It's not our codepoint, we should say nothing about it, just
be careful that our "v4/v6" wording does not accidentally imply that
this can be done with v5.

Stephen: there are mixed views, not all represented in the room, we will
have to discuss on the lst.

Out of time

Look for an interim probably in April.

The following agenda items will be brought to the list: Potential drafts
for adoption

• draft-huigens-openpgp-persistent-symmetric-keys

• draft-gallagher-openpgp-replacementkey

• draft-gallagher-openpgp-hkp

• draft-dkg-openpgp-1pa3pc

• draft-dkg-openpgp-hardware-secrets