[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 would like to add that SafeCurves is woefully outdated.

https://eprint.iacr.org/2015/1060
https://eprint.iacr.org/2014/043


On Fri, Jul 10, 2026 at 9:19 PM Richard Barnes <[e-mail]> wrote:

> 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]
>>
> _______________________________________________
> CFRG mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]
>