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? Regards, Uri > On Apr 1, 2023, at 05:54, Ilari Liusvaara <ilariliusva...@welho.com> wrote: > > On Sat, Apr 01, 2023 at 02:12:14AM +0000, Kampanakis, Panos wrote: >> Hi Bas, >> >> I prefer for the MTI to be P-256+Kyber768 for compliance reasons. > > Uh, I think this thing is too experimental to have any MTI. > >> It would be trivial for servers to add support for both identifiers >> as they introduce Kyber768, but you are right, the new draft should >> include an MTI identifier. > > The problem with having both is that it bifurcates the system. While > being on wrong side is not a hard failure, it is still rather annoying > perf hit. > > For clients to support either, servers must support both. > > At least with P-384 hybrid, folks are less likely to deploy the thing > unless needed. > > > > -Ilari > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
