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

[Ilari Liusvaara <[e-mail]>]

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