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 TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
