> 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.
This strongly suggests that if the “first-rate cryptographers” (and not those playing ones on the Internet) decided that pure ML-KEM is sufficient to protect internal communications of their governments — it is good enough to allow as an option for everyone else. > Exactly how they came up with this conclusion, I cannot say (as I was not > involved). Should it matter, really? > Of course, other governments (with access to equally first-rate > cryptographers) have come > to the opposite conclusion. Some did (Germany), some didn’t (UK, USA). It probably means that their threat model views differ in both breadth and depth from those of the crypto-wannabes who are now flooding this list. It is interesting to note that the proponents of “pure ML-KEM” aren’t trying to push it upon the entire community, but request it as an option . While its opponents are trying to force hybrids down everybody’s throat, presumably because they are convinced that “know better” than the rest of us. ________________________________________ From: Andrew Lee <[email protected]> Sent: Sunday, July 5, 2026 12:32 PM To: Hammell, Jonathan F - [he/il] <[email protected]> Cc: Kevin Milner <[email protected]>; [email protected] <[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]> 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]
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ TLS mailing list -- [email protected] To unsubscribe send an email to [email protected]
