Hi TLS WG, I’m not a cryptographer, but operating from inside a large telco. I wanted to share my perspective.
The WG should publish this document to serve constrained devices and specific regulatory mandates, but we must not deprecate or rush past the hybrid transition. Network operators require both paths to safely manage diverse architectures and multiple jurisdictions without risking severe compliance penalties or disruption to our operating licences. Having both a lean option and a safety net is essential for network operators. Thanks, Wilman From: David Cooper <[email protected]> Sent: 06 July 2026 18:32 To: [email protected] Subject: [TLS] Re: WG Last Call: draft-ietf-tls-mlkem-08 (Ends 2026-07-08) You don't often get email from [email protected]<mailto:[email protected]>. Learn why this is important<https://aka.ms/LearnAboutSenderIdentification> External Email: Check the sender and content before clicking links or downloading. Use the Report button if unsure. I support publication of draft-ietf-tls-mlkem. I agree that the announcement that the Canadian Centre for Cyber Security plans to recommend use of ML-KEM (just as it will with ECDHE-MLKEM) is not an indication that the RECOMMENDED=N flag is meaningless. If the goal is to prevent any government agency or other organization from recommending pure ML-KEM, then setting the RECOMMENDED=N flag will not do this. But then, the IETF declining to publish draft-ietf-tls-mlkem won't do that either. While I understand why many people express a preference for hybrids, I disagree with many of the arguments of those who insist that the publication of draft-ietf-tls-mlkem must be stopped. While for most use cases the additional overhead in terms of code, computation, and data transmission of performing ECDHE-MLKEM rather than ML-KEM will not be a problem, I do not believe that those who choose to use ML-KEM will be "endangered." While it is always possible that new cryptanalysis could break ML-KEM, that is also the case for classical algorithms (such as RSA and ECDH). ML-KEM is not a brand new algorithm based on a new hardness problem that was introduced just a couple of years ago. It is closely related to schemes that were developed well over twenty years ago, and lattice-based cryptography has been studied extensively since then. We cannot lump all PQC algorithms together. The breakage of SIKE says nothing about the maturity level of ML-KEM. While I'm sure it was quite a surprise when SIKE was broken in 2022, the report that NIST published shortly before this break was announced (NIST IR 8413) said that "SIKE seems promising but needs further study, as it is still a relatively new scheme." While one cannot rule out the possibility of implementation bugs, I believe that others have well explained that it is far less likely that there will be implementation bugs that are exploitable in an ephemeral use case. The code points for ML-KEM have been assigned and they are already supported by multiple implementations. What what I can tell, the code points will be specified in an RFC, it is just a question of whether that RFC will be published through the IETF or as an independent submission. Given that this is a good, secure option, useful for those who do not want the overhead of having an implementation of ECDH, and that there is running code, I believe it should be published through the IETF. On 7/5/26 20:34, Scott Fluhrer (sfluhrer) wrote: I'm not exactly sure how this proves anything. Presumably, the Canadian Government has access to first-rate cryptographers, and they have decided that, for protecting internal Canadian Government communications, that pure ML-KEM is sufficient, at least in some cases. Exactly how they came up with this conclusion, I cannot say (as I was not involved). I would speculate that they may have decided that the need for 'post Q-day' security was significant, and for that, hybrid and pure ML-KEM are essentially equivalent. Of course, other governments (with access to equally first-rate cryptographers) have come to the opposite conclusion. What this would indicate to me is perhaps the issue isn't quite as straight-forward as the 'no' people are trying to portray it. ________________________________ From: Andrew Lee <[email protected]><mailto:[email protected]> Sent: Sunday, July 5, 2026 12:32 PM To: Hammell, Jonathan F - [he/il] <[email protected]><mailto:[email protected]> Cc: Kevin Milner <[email protected]><mailto:[email protected]>; [email protected]<mailto:[email protected]> <[email protected]><mailto:[email protected]> Subject: [TLS] Re: WG Last Call: draft-ietf-tls-mlkem-08 (Ends 2026-07-08) Dear Jonathan, > On Jul 5, 2026, at 9:06 AM, Hammell, Jonathan F - [he/il] > <[email protected]><mailto:[email protected]> wrote: > > Yes, the Canadian Centre for Cyber Security plans to recommend the use of > ML-KEM for TLS in our guidance for configuring network security protocols > (ITSP.40.062 [3]). We hope it will be published as an RFC. > Thank you for confirming, on the record, that the Canadian government plans to recommend solo ML-KEM for TLS despite the document carrying a RECOMMENDED=N flag. This is the single most important piece of evidence in this entire debate, because it proves that RECOMMENDED=N is meaningless in practice. To make matters worse, X25519MLKEM768 is already flagged RECOMMENDED=Y in the IETF TLS registry. Yet, the Cyber Centre plans to treat both equally. You are explicitly overriding the IETF's own recommendation to present a downgrade as equivalent to the recommended option. This is precisely what Dr. Bernstein, Dr. Tanja Lange, Dr. Nadim Kobeissi, Dr. Orr Dunkelman, and many other highly credentialed and deeply involved participants have been warning about [1]. The "Not Recommended" flag was supposed to be the safeguard that made publication acceptable. You proved it is not. Critically, I would ask the chairs to take note of this statement when evaluating consensus. The core argument for publication was that RECOMMENDED=N protects against misuse. A Five Eyes government, mind you, just told us on this mailing list, that it does not. Sincerely, Andrew [1] If I didn't name you by name, I humbly apologize deeply. _______________________________________________ TLS mailing list -- [email protected]<mailto:[email protected]> To unsubscribe send an email to [email protected]<mailto:[email protected]> VodafoneThree Holdings Limited is the holding company of Vodafone Limited and Hutchison 3G UK Limited and this email is sent on behalf of Vodafone Limited and/or Hutchison 3G UK Limited. The message and any attachment(s) are confidential, may be legally privileged and are intended solely for the attention of the addressee(s). If you are not the intended recipient or you have received this email in error, please notify the sender immediately, delete it and any attachments from your system and do not copy, disclose or use its contents for any purpose. This transmission cannot be guaranteed to be secure or error-free. Any views or opinions expressed in this message are those of the author only. Vodafone Limited. Registered in England & Wales | Company no 01471587. Vodafone House, The Connection, Newbury, Berkshire, RG14 2FN. Authorised & Regulated by the Financial Conduct Authority for consumer credit lending and insurance distribution activity (Financial Services Register No. 712210). Hutchison 3G UK Limited. Registered in England and Wales | Company number 3885486. Registered Office: 450 Longwater Avenue, Green Park, Reading, Berkshire, RG2 6GF. Authorised & Regulated by the Financial Conduct Authority for consumer credit (Financial Services Register No. 738979). VodafoneThree is a holding company of Vodafone Limited and Hutchison 3G UK Limited, see www.VodafoneThree.com<https://www.vodafonethree.com> to learn more. C2 General
_______________________________________________ TLS mailing list -- [email protected] To unsubscribe send an email to [email protected]
