Hi, Bas Westerbaan wrote: >I think it'd very bad if we'd have a codepoint for pure ML-KEM before we have >a codepoint for an ML-KEM >hybrid. I think that's up to the designated experts of the IANA registry.
Agree. We plan to use hybrid key exchange as the default, but would like to offer pure ML-KEM to customers that want that. As Deirdre states hybrid are a big 'maybe' at best for 'hybrid solutions'. Being able to offer CNSA 2.0 compliant TLS is essential for many companies. I weould like to see standards track ML-KEM as well as standards track ML-DSA just like in IPSECME and LAMPS. Deirdre Connolly wrote: >My current draft does not include ML-KEM-512, mostly because there seems to be >alignment around >ML-KEM-768 being ~equivalent to say X25519 or P-256 ECDH in terms of security >level. I'm not married >strongly to excluding it but that was kind of the thinking. I don't think there is any such alignment. NIST latest assessment is that “the most plausible values for the practical security of Kyber512 against known attacks are significantly higher than that of AES128”. Ericsson agrees with that assessment and so do Sophie Schmieg (Google). https://csrc.nist.gov/csrc/media/Projects/post-quantum-cryptography/documents/faq/Kyber-512-FAQ.pdf https://keymaterial.net/2023/11/18/kyber512s-security-level/ Cheers, John Preuß Mattsson From: TLS <tls-boun...@ietf.org> on behalf of Deirdre Connolly <durumcrustu...@gmail.com> Date: Thursday, 7 March 2024 at 05:37 To: Orie Steele <orie@transmute.industries> Cc: Bas Westerbaan <bas=40cloudflare....@dmarc.ietf.org>, TLS@ietf.org <tls@ietf.org> Subject: Re: [TLS] ML-KEM key agreement for TLS 1.3 > Isn't support for the component mandatory to support the hybrid anyway? Strictly speaking, not necessarily: I could see support for X-Wing or another hybrid key agreement as a standalone unit, both from a software dependency perspective and protocol API perspective. Whether that works in the long term that also supports the standalone component algorithms, that's another question On Wed, Mar 6, 2024, 11:30 PM Orie Steele <orie@transmute.industries> wrote: Does the argument about hybrid code points first generalize to all PQ Code points? Is it equally true of hybrid signatures? I don't understand why registering composite components first wouldn't be assumed. Isn't support for the component mandatory to support the hybrid anyway? Let's assume CRQC drops tomorrow, why did we not register ML-KEM first? Assume it never drops, you still needed to implement ML-KEM to use the hybrid. If the goal is to prohibit ML-KEM without a traditional component, just register it as prohibited. OS On Wed, Mar 6, 2024, 10:10 PM Bas Westerbaan <bas=40cloudflare....@dmarc.ietf.org<mailto:40cloudflare....@dmarc.ietf.org>> wrote: Back to the topic at hand. I think it'd very bad if we'd have a codepoint for pure ML-KEM before we have a codepoint for an ML-KEM hybrid. Process wise, I think that's up to the designated experts of the IANA registry. Best, Bas On Wed, Mar 6, 2024 at 3:16 AM Deirdre Connolly <durumcrustu...@gmail.com<mailto:durumcrustu...@gmail.com>> wrote: I have uploaded a preliminary version of ML-KEM for TLS 1.3<https://datatracker.ietf.org/doc/draft-connolly-tls-mlkem-key-agreement/> and have a more fleshed out<https://protect2.fireeye.com/v1/url?k=31323334-501cfaf3-313273af-454445554331-54a8abb1f5074a30&q=1&e=f3ccb8d0-4979-4456-a3bd-3a45756e7a5b&u=https%3A%2F%2Fgithub.com%2Fdconnolly%2Fdraft-tls-mlkem-key-agreement> version to be uploaded when datatracker opens. It is a straightforward new `NamedGroup` to support key agreement via ML-KEM-768 or ML-KEM-1024, in a very similar style to -hybrid-design<https://datatracker.ietf.org/doc/draft-ietf-tls-hybrid-design/>. It will be nice to have pure-PQ options (that are FIPS / CNSA 2.0 compatible) ready to go when users are ready to use them. Cheers, Deirdre _______________________________________________ TLS mailing list TLS@ietf.org<mailto:TLS@ietf.org> https://www.ietf.org/mailman/listinfo/tls _______________________________________________ TLS mailing list TLS@ietf.org<mailto:TLS@ietf.org> https://www.ietf.org/mailman/listinfo/tls
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
