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

[Simon Josefsson <[e-mail]>]

Hi,

Even as editor of two of the "Security Considerations" documents, I have
my doubts we are looking at this problem from the right angle.

What I believe would provide value to the IETF community is for CFRG to
adopt and publish KEM specifications that describe algorithms (with
parameter choices) that are relevant for IETF protocols.  These include
draft-longa-cfrg-frodokem, draft-josefsson-mceliece and (the less
fleshed out) draft-josefsson-ntruprime-streamlined.  Beyond that, it
would be nice to have X-Wing and other hybrid instances published.

There is a lot of subtlety in each of PGP, TLS, SSH, JSON etc that is
difficult to discuss in a generic security considerations documents.
The CFRG doesn't have domain expertise for each of those protocols.
Attempting to say anything useful on a generic level requires inventing
some framework or model of how the KEMs will be applied, and that can
get fairly complex (quite similar to all the complexity introduced by
the hybrid KEM documents).  Still it would probably not say enough
useful for the actual IETF protocols wanting to use it.

Thus, I think what we could do is to take all these documents, combine
them, remove some of the more speculative discussions, and publish it as
a "KEM Considerations" which would serve as a reference point for other
IETF WGs to understand which KEMs, and which KEM parameters, are
well-known and some trade-offs for each algorithm.  But keep it fairly
basic.  I see no reason to hold a competition or excluding some
well-known KEMs, but instead include discussion of all the KEMs with at
least some notability: ML-KEM, Classic McEliece, Streamlined NTRU Prime,
FrodoKEM, HQC, NTRU and maybe some more that I forget.  What do you
think?  Can we reasonably finish a larger assignment?

/Simon

Nick Sullivan <[e-mail]> writes:

> Dear CFRG,
>
> There has not been a lot of conversation about the topic of KEM Security
> considerations, so please weigh in if you're interested in the CFRG
> adopting this topic or have opinions on the shape of the adoption call. We
> need participants' voices to help guide the decisions. Given this, we plan
> to have an open discussion at the next meeting and invite all interested
> parties to participate.
>
> Best,
> Nick (for the chairs)
>
> On Tue, Jun 23, 2026 at 6:40 PM Nick Sullivan <[e-mail]>
> wrote:
>
>> 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.
>>
> _______________________________________________
> CFRG mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]
>