Re: [TLS] Consensus call on codepoint strategy for draft-ietf-tls-hybrid-design

["Blumenthal, Uri - 0553 - MITLL" <[e-mail]>]

That is correct - CNSA-2.0 prescribes the “NIST Kyber”, whatever changes this may include to the Kyber-1024, aka Kyber at NIST Sec Level V. 

One can speculate about what changes would be proposed during the public comments period, and which of them would be accepted. Regardless, until then we won’t know the *exact* details of the algorithm. 

However, if people consider experimenting with Kyber deployment now, and want to define appropriate MTI now (and want to use Hybrid, aka combined, key exchange) - then it’s as pointless now as it will be in the future to define P384+Kyber768, because either there won’t be such a Hybrid at all (NSA stated that they won’t require Hybrid in products that need their certification) or there will be P384+Kyber1024, whatever the latter will look like then. 

Regards,
Uri

> On Apr 2, 2023, at 06:43, Ilari Liusvaara <[e-mail]> wrote:
> 
> On Sun, Apr 02, 2023 at 02:54:57AM +0000, Blumenthal, Uri - 0553 - MITLL wrote:
>> CNSA-1.0 allows ECC only over P-384, unlike it’s predecessor Suite B
>> that also permitted P-256. P-521 is not included either. See
>> https://media.defense.gov/2021/Sep/27/2002862527/-1/-1/0/CNSS%20WORKSHEET.PDF
>> (page 1).
>> 
>> CNSA-2.0 allows only Kyber-1024. Not -768. See https://media.defense.gov/2021/Sep/27/2002862527/-1/-1/0/CNSS%20WORKSHEET.PDF
>> (page 4).
>> 
>> So, if somebody would insist on a CNSA-compliant hybrid - there is
>> only one candidate from each group to consider for the MTI. 
>> 
>> It also means that MTI für P-384 with Kyber-768 is likely to be quite
>> useless, as those not bound by CNSA would probably make other choices
>> (not P-384)  anyway, and those required to comply with CNSA will have
>> to settle for what I described. 
>> 
>> Did I make it clear enough? Or do you see a hole in my logic?
> 
> I think what "CRYSTALS: Kyber" means in CNSA-2.0 is the final
> specification. Which obviously is not available yet, so it is impossible
> to currently make any key exchange or asymmetric encryption compliant
> with CNSA-2.0.
> 
> As to what sense does publishing CNSA-2.0 before the algorithms are
> known make? Note that it does have algorithms for firmware signing
> fully specified, and urges those to be deployed as soon as possible.
> And I suppose there might be sense timing-wise on publishing a spec
> referencing a future spec that will likely undergo nontrivial draft
> period.
> 
> 
> 
> -Ilari
> 
> _______________________________________________
> TLS mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/tls