I (of course) cannot answer for Jonathan much less the Canadian government, but several were given in this list already, for example https://mailarchive.ietf.org/arch/msg/tls/_9i3uIVDQ3pDRswpm9US-E-X2cA/ ML-KEM and SHA-3 are fast, well-suited for hardware implementation, and do not share hardware resources with slower ECC operations. If you believe CRQC’s will come to exist within the lifespan of your hardware product, then (and apologies for quoting you back to yourself) why would you have "plans to treat a limited-applicability, specific-use-case option" (the hybrid PQC/ECC version, taking more hardware and applicable only for another few years depending on your CRQC timeline) the same as the faster and cheaper pure ML-KEM version?
Being published as an RFC means that the IETF maintains security guidance and standardises and implementation. This seems a good reason for an agency who plans to recommend the use of pure ML-KEM to want that, it means they don’t have to maintain it themselves. But I doubt the existence of an RFC will influence their recommendations; it hasn’t influenced the CNSA. Anyway, I think I have made my opinion clear, if you wish to recommend against pure ML-KEM then I believe the working group should publish a document to that effect (fortunately, one is up for last call right now). As pointed out elsewhere on the list, effectively every major TLS library has already implemented pure ML-KEM, and I personally believe it is this working group’s prerogative to give those implementers specific and clear standards around whether it should be used, as well as providing an authoritative source for any associated security guidance that might need to be revised over time. Cheers, Kevin > On 5 Jul 2026, at 17:56, Andrew Lee <[email protected]> wrote: > > 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]
