>It is obvious that pure PQ KEMs are the future I am not sure about that. X25519MLKEM768 is already quickly becoming the new de facto standard (google.com, ericsson.com, government.se, etc. are already using it, likely thanks to Cloudflare).
Do you seriously expect governments and standards bodies to keep approving X25519 component after CRQC existence becomes public knowledge? What purpose would it serve then? It is already compliant with NIST specifications and soon it will be possible to get FIPS certification. Not clear that the benefits of migrating from X25519MLKEM768 to MLKEM768 will be worth it performance and marketing wise. Do you mean that, e.g., NIST will keep then-broken X25519 in the standard until MLKEM is obsoleted too? It is not impossible – but I find it rather hard to believe. From: Stephen Farrell <stephen.farr...@cs.tcd.ie> Date: Sunday, 15 December 2024 at 15:33 To: Blumenthal, Uri - 0553 - MITLL <u...@ll.mit.edu> Cc: tls@ietf.org <tls@ietf.org> Subject: [TLS] Re: [EXT] Re: draft-connolly-tls-mlkem-key-agreement Hiya, On 15/12/2024 02:33, Blumenthal, Uri - 0553 - MITLL wrote: > Stephen, I don’t think attempting to develop consensus in this case > would be either useful or productive. Strongly disagree. I think we ought consider it our duty to develop guidance for those deploying e.g. TLS now that we're adding a plethora of new ciphersuites, some useful, some way less so, and some possibly even risky. >... > Thus, I don’t think there’s a way to bring these two camps together, > nor do I see a need for that. I have no desire to affect the opinions of the sigint agencies who have come up with 100% contradictory positions. It's not them I care about at all, but rather those deploying the set of protocols we develop here. > Let TLS offer both hybrid and pure > KEMs. For TLS, that's inherent in our current IANA regisration model and has already happened. > And be done with it. My point is that we are not done with it - we should be offering guidance on what to use when. If we do not do that, IMO we'd be doing a disservice to the Internet community. Cheers, S.
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
