MLKEM1024 is the CNSA 2.0 approved key exchange https://www.ietf.org/archive/id/draft-becker-cnsa2-tls-profile-00.html <https://www.ietf.org/archive/id/draft-becker-cnsa2-tls-profile-00.html>
Yes. secp384r1 is the CNSA 1.0 approved key exchange https://www.rfc-editor.org/rfc/rfc9151.html <https://www.rfc-editor.org/rfc/rfc9151.html> Yes. 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). No. MLKEM768 is not allowed by CNSA-2.0. Only MLKEM1024. 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>
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
