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

[박종환_교수_컴퓨터과학전공 <[e-mail]>]

Hi, all,

This is Jong Hwan Park. As a newcomer to the CFRG community and the editor
of the NTRU+ security considerations draft, I am still becoming familiar
with the way these discussions are conducted.

We now have six per-KEM security considerations drafts submitted to the
CFRG, including ML-KEM, FrodoKEM, Classic McEliece, Streamlined NTRU Prime,
NTRU+, and NTRU (with NTRU-HPS and NTRU-HRSS also being relevant in this
context). I believe that each of these KEMs has unique characteristics that
deserve careful consideration, and different protocols may ultimately
choose different KEMs depending on their requirements.

Regarding Simon's suggestion:

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

I respectfully disagree with using "notability" as a criterion for deciding
which KEMs should be discussed. It is not clear to me what objective
standard "notability" refers to. For example, NTRU+ was not included in the
list, despite offering highly competitive performance. In particular, NTRU+
currently achieves the fastest performances among the submitted KEMs at
comparable security levels. I therefore believe that objective technical
characteristics, rather than perceived notability, should guide the scope
of any comparative discussion.

More importantly, however, my understanding is that the current CFRG
discussion is *not* about selecting or recommending one or more KEMs.
Instead, it is about identifying the security considerations that protocol
designers and implementers should understand when deploying a particular
KEM.

When preparing the NTRU+ draft, I was particularly looking forward to
discussions on issues that are specific to protocol integration, such as
the implications of *explicit rejection versus implicit rejection*, which
may affect the design of protocols such as IKEv2, OpenPGP, and WireGuard. I
also expected discussion of implementation-related topics, such as *Pairwise
Consistency Tests (PCTs)* for KEM key generation when CMVP/FIPS 140-3
validation is required.

I support adopting the topic proposed by Nick, and I look forward to the
next stage of the discussion.

Best regards,

Jong Hwan Park


2026년 7월 11일 (토) 오전 9:01, Simon Josefsson <simon=
[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]
> >
> _______________________________________________
> CFRG mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]
>