[CFRG] Per-KEM security considerations: drafts received, and a two week comment period

[Nick Sullivan <[e-mail]>]

Hi CFRG,

Thanks to everyone who responded to the April call. The June 22 window
has closed, and we have a good set of per-KEM security considerations
documents to work with. Before we talk about adoption, the chairs
would like to open a two-week comment period so the group can read and
react to all of them together. Please send comments to the list by
Tuesday, July 7. This will help the chairs decide which documents will form
the basis of an adoption call for the topic.

Here is what came in:

ML-KEM (the existing document):
https://datatracker.ietf.org/doc/draft-sfluhrer-cfrg-ml-kem-security-considerations/
FrodoKEM: https://datatracker.ietf.org/doc/draft-longa-cfrg-frodokem-security-considerations/
Classic McEliece:
https://datatracker.ietf.org/doc/draft-josefsson-cfrg-mceliece-considerations/
Streamlined NTRU Prime:
https://datatracker.ietf.org/doc/draft-josefsson-cfrg-sntrup-considerations/
NTRU+: https://datatracker.ietf.org/doc/draft-jhpark-cfrg-ntruplus-security-considerations/
NTRU: draft-kosuge-cfrg-ntru-kem-security-considerations (announced,
being posted to the datatracker, link to follow shortly)
NTRU-family review checklist:
https://datatracker.ietf.org/doc/draft-liu-cfrg-ntru-family-security-considerations/

One thing stands out. We now have multiple documents in the NTRU family:
the NTRU document, NTRU+, and the NTRU-family checklist. There is real
overlap between them, and we'd encourage those authors to compare
notes and consider combining forces, whether that means a shared
checklist the per-KEM documents build on or some other split. Comments
from the group on how best to structure that are welcome.

To be clear on scope, this comment period is about the documents
written in response to this call, and it is not the adoption call
itself. The plan is a single adoption call for the topic, informed by
the discussion here, rather than a separate call for each document.
These don't need to be complete or final to be useful. They just need
to be a solid starting point for a working group document. If you
already think one is a good basis to work from, please say so, that's
useful signal for the adoption call. People developing IETF protocols
who are considering any of these KEMs are also encouraged to
contribute their perspectives.

What's most useful right now: whether each document answers the
checklist from the call, where it's thin, and whether you'd be willing
to review or implement. We'll take stock after July 7.

Thanks,
Nick (for the CFRG chairs)

For authors: if you haven't signed up for the CFRG mailing list,
please do so here:
https://mailman3.irtf.org/mailman3/lists/[e-mail], which is where
the discussion is happening.