Dear Kevin, Jonathan said, and I quote, “We hope it will be published as an RFC.” This would not, under any adjudicator’s interpretation, indicate indifference regarding the publication of the RFC.
I also want to note that Dr. Kobeissi has posited a great question, "Could you please give examples of potential use cases where the Cyber Centre envisions that ML-KEM would be a preferable choice to ECDHE-MLKEM?” I hope you or Jonathan can be quick to respond here as well! Cheers, Andrew > On Jul 5, 2026, at 9:48 AM, Kevin Milner <[email protected]> wrote: > > Hi Andrew, > > I appreciate your enthusiasm to respond but I interpreted Jonathan's > statement to say that they plan to recommend the use of ML-KEM independently > of whether there is an RFC, perhaps he can confirm one way or another. > > This would seem to lend credence to the suggestion that publishing the RFC > itself is irrelevant to the recommendations of national security agencies, > and indeed perhaps that (should consensus indicate it) publishing an RFC with > Recommended=N would be an excellent way to communicate to the wider community > that our collective stance is to recommend against its use, rather than > having no specification one way or another and leaving only the perspective > of national security agencies represented in published documents. > > Cheers, > Kevin > >> On 5 Jul 2026, at 17:32, Andrew Lee <[email protected]> wrote: >> >> Dear Jonathan, >> >>> On Jul 5, 2026, at 9:06 AM, Hammell, Jonathan F - [he/il] >>> <[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] To unsubscribe send an email to [email protected]
