[CFRG] Re: RG Last Call on draft-irtf-cfrg-hybrid-kems-12 and draft-irtf-cfrg-concrete-hybrid-kems-04

[Soatok Dreamseeker <[e-mail]>]

I support publication of both documents.

The generic framework is useful for defining new KEMs should we need to
specify them in the future (e.g., if there is a novel attack on one of the
KEMs standardized), and the concrete KEMs doc is useful for implementors
today.

I've re-read both documents and believe they introduce a lot of
> complexity to specify four generic frameworks that ultimately is then
> used to specify only three hybrid KEM instances (which all three use
> only one of the frameworks): X-Wing, MLKEM768-P256, MLKEM1024-P386.
>
> Which IETF protocols will use the non-XWing variant?  Is this
> TLS-specific?


While the concrete KEMs draft all use the same framework, this is only
secure because of the binding properties of the underlying KEM chosen by
that spec. Other KEMs may need a different combiner to achieve the security
goals (i.e., they may need to include more data into the KDF call to be
secure, while ML-KEM doesn't impose such a requirement).

One of the authors of both documents touched on this lightly a few years
ago: https://durumcrustulum.com/2024/02/24/how-to-hold-kems/

And there's some formal verification results that might be interesting:
https://cryptographycaffe.sandboxaq.com/posts/keeping-up-with-the-kems-formally-easycrypt-edition/

This is why a separate document discussing frameworks is valuable, even if
the actual concrete examples today do not need most of that other doc.

Please let me know if anything I said is unclear.

On Fri, Jul 10, 2026 at 7:32 PM Simon Josefsson <simon=
[e-mail]> wrote:

> Hi
>
> I've re-read both documents and believe they introduce a lot of
> complexity to specify four generic frameworks that ultimately is then
> used to specify only three hybrid KEM instances (which all three use
> only one of the frameworks): X-Wing, MLKEM768-P256, MLKEM1024-P386.
>
> Which IETF protocols will use the non-XWing variant?  Is this
> TLS-specific?
>
> Is there any IETF or CFRG activity to specify other variants?  Would any
> use the non-CG frameworks?
>
> I believe all of this complexity is detrimental to security and poor use
> of engineering time.  If only ever three instances are to be described
> and used, all of the generic parts of the document serves little
> purpose.  If only one framework has known instances, it seems difficult
> to have confidence in completeness of the non-CG frameworks.
>
> The community appears to want X-Wing, and I believe that document should
> be published.  If there are IETF protocols that will use the
> MLKEM768-P256 or MLKEM1024-P386 hybrids, then consider publishing them
> as standalone documents like draft-connolly-cfrg-xwing-kem-10.  Very
> little of the generic parts are needed to do that.  Those are the
> primitives that IETF protocols generally is looking for.
>
> If there is no other planned or in-progress use of the other frameworks
> or variants, then consider just removing them from the document.
>
> Re Appendix A of cfrg-hybrid-kems, I wonder if this is ideas is even
> generally applicable?  I don't think all KEMs necessarily consume
> randomness in a serialized quantiative way which the idea assumes.
>
> /Simon
>
> Nick Sullivan <[e-mail]> writes:
>
> > Dear CFRG,
> >
> > This message starts a two-week RG Last Call on two related documents. The
> > last
> > call ends on Wednesday July 22, 2026:
> >
> >   Hybrid PQ/T Key Encapsulation Mechanisms (generic constructions)
> >   draft-irtf-cfrg-hybrid-kems-12
> >   https://www.ietf.org/archive/id/draft-irtf-cfrg-hybrid-kems-12.html
> >
> >   Concrete Hybrid PQ/T Key Encapsulation Mechanisms
> >   draft-irtf-cfrg-concrete-hybrid-kems-04
> >
> >
> https://www.ietf.org/archive/id/draft-irtf-cfrg-concrete-hybrid-kems-04.html
> >
> > Both are intended as Informational RFCs. Please reply on-list with your
> > position
> > on each document: ready to publish as-is, ready with specific changes, or
> > not
> > ready, together with the technical reasons. This feedback will help the
> > chairs
> > judge whether the documents are ready for IRSG review and publication.
> >
> > The scope and approach of this work were settled when the group adopted
> it
> > well
> > over a year ago, and both drafts have developed on the list in the open
> > since
> > then. This last call is about whether the text is technically correct and
> > complete, so please ground any objection in a specific problem with the
> > documents. Detailed comments are best filed as issues on the repositories
> > (https://github.com/cfrg/draft-irtf-cfrg-hybrid-kems,
> > https://github.com/cfrg/draft-irtf-cfrg-concrete-hybrid-kems) positions
> > belong
> > here on the list.
> >
> > Both documents were reviewed by the CFRG Crypto Review Panel ahead of
> this
> > last
> > call. The reviews are on the CFRG and crypto-panel lists:
> >
> >   Thomas Pornin (NCC Group), 3 June 2026, reviewed the generic framework
> > with a
> >   focus on the constructions and reductions, and concluded that it
> > describes a
> >   secure construction, with editorial and technical comments now
> reflected
> > in -12.
> >
> >   Virendra Kumar (Qualcomm), 8 June 2026, reviewed the generic framework
> for
> >   clarity, with notational comments now reflected in -12.
> >
> >   Russ Housley (Vigil Security), 2 June 2026, reviewed both drafts and
> > found the
> >   constructions and instantiations as specified.
> >
> > The current revisions incorporate changes proposed by the panel's
> comments.
> >
> > Thank you,
> > Nick, for the CFRG chairs
> > _______________________________________________
> > 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]
>