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

[Simon Josefsson <[e-mail]>]

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]
>