Blumenthal, Uri wrote: >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). 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.
Stephen Farrell wrote: >we should be offering guidance on what to use Agree. I think the best way to do that is to adopt and publish draft-kwiatkowski-tls-ecdhe-mlkem as standard track, and make X25519MLKEM768 RECOMMENDED=Y and MTI as soon as possible. Cheers, John 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.
_______________________________________________ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
