I also have a hard time too see why it is needed. MLKEM1024 is the CNSA 2.0 approved key exchange https://www.ietf.org/archive/id/draft-becker-cnsa2-tls-profile-00.html
secp384r1 is the CNSA 1.0 approved key exchange https://www.rfc-editor.org/rfc/rfc9151.html If SecP3841MLKEM1024 is CNSA 1.0 compliant (treating MLKEM102 like a non-security part), then X25519MLKEM768 is CNSA 2.0 compliant (treating X25519 like a non-security part). From: Bas Westerbaan <[email protected]> Date: Monday, 6 January 2025 at 11:18 To: Kris Kwiatkowski <[email protected]> Cc: [email protected] <[email protected]> Subject: [TLS] Re: draft-kwiatkowski-tls-ecdhe-mlkem and x448 Didn't CNSA 2 only allow hybrids if there is no alternative? There is a codepoint for MLKEM1024 in TLS now. On Mon, Jan 6, 2025 at 9:57 AM Kris Kwiatkowski <[email protected]<mailto:[email protected]>> wrote: Sure, but for the record the same applies to SecP3841MLKEM1024 I think the main motivation for ECDH/P-384 is CNSA compliance, so I don't think it is "the same applies". Yes, it is slower than x25519 or ECDH/p256. _______________________________________________ TLS mailing list -- [email protected]<mailto:[email protected]> To unsubscribe send an email to [email protected]<mailto:[email protected]>
_______________________________________________ TLS mailing list -- [email protected] To unsubscribe send an email to [email protected]
