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 <bas=40cloudflare....@dmarc.ietf.org> Date: Monday, 6 January 2025 at 11:18 To: Kris Kwiatkowski <k...@amongbytes.com> Cc: tls@ietf.org <tls@ietf.org> 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 <k...@amongbytes.com<mailto:k...@amongbytes.com>> 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 -- tls@ietf.org<mailto:tls@ietf.org> To unsubscribe send an email to tls-le...@ietf.org<mailto:tls-le...@ietf.org>
_______________________________________________ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
