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

[Richard Barnes <[e-mail]>]

This message is a reply to D. J. Bernstein, but not directly on account of
not wanting to run afoul of his copyright lawyering.

1. "Combiners should rely on a single security target for KEMs.  This
single security target should be IND-CCA2."

If that is your position, you are free to use only the U* combiners.
Others in the working group argued that the efficiency benefit of the C*
combiners was worth the additional assumption.  There was a clear consensus
call to support both models about a year ago, and the document is clear on
the limitations of C*.


2. "I see no justification for the complication of specifying more than one
combiner."

Here is the justification: As I said in my message to Simon, there is
already work using the CG and CK combiners, and the U* combiners are there
to accommodate those who, like you, do not wish to rely on the C2PRI
property of the PQ KEM.


3. "I see no justification for the complication of allowing NIST P-256 as
another option."

Here is the justification: Some implementers want to use P-256, e.g., the
MLS working group.  It's not CFRG's position to limit options, just to
provide information to WGs about which options are safe, and P-256 is.


On Wed, Jul 8, 2026 at 12:26 AM Nick Sullivan <[e-mail]>
wrote:

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