Notes from the CFRG research group meeting at IETF 123 (Madrid)
Thursday July 24, 2025, 17:00-19:00 (UTC+2)
https://meetings.conf.meetecho.com/ietf123/?session=34257
Jabber: cfrg@jabber.ietf.org
Notes: https://notes.ietf.org/notes-ietf-123-cfrg
Chairs: Alexey Melnikov, Stanislav Smyshlyaev and Nick Sullivan
Note Taker: Scott Fluhrer
Pain points from IETF 122: CFRG has been requested to produce documents
factorm and giving immediate guidance to protocol designers and
implementors (which is not what this RG is for)
New RFCs: RFC 9771 (Properties of AEAD algorithms) and RFC 9807 (OPAQUE)
Proposal for IETF 124; a two hour slot for new work, and a separate one
hour slot for consensus
The goal was to provide guidance to non-cryptographs, provide some
targets for the ecosystem, and align with LAMPS, OpenPGP, X-Wing. The
result: a generic doc, and a concrete doc. The generic doc has several
alternatives, some of which assume some properties from the KEM (C2PRI),
with some performance differences. The concrete doc gives three
instantiations. The draft team thinks the engineering part is good; the
research part needs more work.
MikeO: The LAMPS hybrid KEM is close to, but not exactly the same, as
this. The differences are deterministic key generation, and SHA-2 vs
SHA-3.
Several comments of the form: "lets get this done and ship it"
Chair (Nick): We'll have a virtual interim in September to nail this
down
NTRU is another postquantum KEM, with similar security and performance
characteristics to ML-KEM. Suggested as a cryptoagility alternative to
ML-KEM.
Classic McEliece is a postquantum KEM based on the decoding problem;
huge public keys, tiny ciphertexts, no successful cryptanalytic results.
Would be useful in applications that can cache the public key.
General discussion about whether if (and if so, how) the CFRG should
address these alternative KEMs.
Richard Barnes: What problem is being solved by this? Is there a real
need for the CFRG to work on this?
Deirdre: One problem being addresses is cryptoagility; a break to ML-KEM
is unlikely to affect McEliece. However, it is unclear if the CFRG is
the right place.
Christopher Patton: One thing we can help is helping working groups to
decide whether to rely on different computational assumptions; giving
engineers the tools to make decisions.
Uri Blumenthal: We need to consider the diversity of hard problems -
also, how close are the disparate hard problems - have we really
considered that?
Watson: What is the reason for an algorithm RFC? Unless we understand
that, the rest is unanswerable.
Patrick Longa: Reiterated the need for diversity. We also need some
conservative options out there.
Poll: Are we convinced that the problem being solved by adopting a PQ
KEM for CFRG is well-defined and well-motivated? Yes: 16, No: 39, No
opinion: 14
Poll: Is the CFRG the right venue to pursue this work? Yes: 40, No: 26,
No opinion: 14
Poll: Do we need a KEM requirements document before proceeding with any
specific KEM adoption? Yes: 45, No: 19, No Opinion: 9
Mechanism where the signer can sign a list of messages, the prover
discloses a subset of these messages to disclose, and provides a proof
that these messages were in the list. Pseudonyms: adding unlinkability
to the above.
However, if you can solve a discrete log, you can link signatures (I
think - I had a hard time following it). This is a proposal to address
that.
Is there interest for doing research PQ ZK schemes for proving "simple
theorems" (expressable in a simple circuit)? There is existing work
(such as one relying on SHA-256 only) - they have such a scheme. This is
boring crypto, well researched.
Deirdre: I support this work
Watson: I support this work. But, what would this look like in the CFRG?
A: I believe that this can be addressed, we can talk off-line
Christopher Patton: We need to understand what the problem we want to
solve first, before we take this on. But, it does sound like this is it.
Sigma protocols are common, but are designed individually. Should we
come up with a standard building block? This would have better security
(one place to fix) and better analysis (one target for further
analysis).
There are two specs: one for an interactive Sigma protocol, and one for
a noninteractive Fiat-Shamir. It is a work in progress, based on
feedback.
Open questions: Can we converge on one design? A: we're trying to
converge; does the Sigma spec capture your optimizations?
Should we support compressed sigma protocols? Should we support
composability? Anything else?
Uri Blumenthal: Can we have a P-384 instead?
Sofia Celi: Supporting composition would be very nice - it was seen done
wrong too many times
Abhi Shelat: Could you consider straight line extractability - it was
required when I did it
Deirdre: I don't see them in the CFRG-related internet drafts. However,
the can be tricky - this would be useful
Dennis Jackson: We need to do this - it'll take time, and so sooner
rather than later would be good
An AEAD encryption scheme - shown to be immune to common cryptanalytic
attacks, and the speaker gave comparisons with other schemes.
ChaCha-Poly1305 does not meet many of the properties in RFC 9771. This
is an effort to fix that.
They replace the polynomial hash with Poly1163.
Scott Fluhrer: combining ChaCha and Poly1305 can be done wrong, hence it
might be nice for the RG to document how to do to it right.
Postquantum PAKEs exist mainly in the literature.
We want a postquantum PAKE: augmented and hybrid, based on standard
assumtions (ROM) and ML-KEM.
They have a specific proposal (OQUAKE); does make stronger assumptions
on ML-KEM. They also have a hybrid version (CPaceOQUAKE), which does
CPACE and then does OQUAKE on the CPACE generated shared secret, and an
augmented version. Does require multiple round trips.
Christopher Patton: PQ PAKE would be great. I am definitely concerned
about the extra round for hybrid. How does this compare to generic
combiners? Answer is offline.