Dear Jonathan, You write that the Canadian Centre for Cyber Security plans to recommend both ML-KEM and ECDHE-MLKEM without recommending one over the other, "as it may be a use case specific decision".
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 ask purely because I personally can’t imagine use cases where such a decision would make more sense on the technical level. The only thing I can come up with is a policy-level restriction, which puts this question aside the realm of technical deliberation and therefore makes it less interesting to me. I’m completely willing to accept that this could be a failure of my imagination, or a lack of insight on my part. I would appreciate being educated on where such instances are predicted to potentially exist. Thank you, Nadim Kobeissi Symbolic Software • https://symbolic.software > On 5 Jul 2026, at 6:06 PM, Hammell, Jonathan F - [he/il] > <[email protected]> wrote: > > UNCLASSIFIED / NON CLASSIFIÉ > > I support publication. > > On Wed, Jul 1, 2026 at 5:59 PM Andrew Lee <[email protected]> wrote: >> On Jul 1, 2026, at 2:22 PM, Kevin Milner <[email protected]> wrote: >>> It’s important to separate opposition to the rollout of non-hybrid PQC >>> from opposition to this draft. >> >> Someone from the Canadian Centre for Cyber Security (Canadian >> Government) literally wrote on list they are relying on this document >> to be published so they can recommend solo ML-KEM [0][1], and an >> expert PQ cryptographer [2] pointed this out in addition to their >> opposition. > > 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. > > However, contrary to assumptions made by others, the Cyber Centre also plans > to recommend hybrid ECDHE-MLKEM as per draft-ietf-tls-ecdhe-mlkem. > Therefore, our general guidance is not recommending one over the other, as it > may be a use case specific decision. We want the migration to PQC to be as > easy as possible to have vendors and organizations meet our timelines [4]. > > Jonathan > > [3] > https://www.cyber.gc.ca/en/guidance/guidance-securely-configuring-network-protocols-itsp40062 > [4] > https://www.cyber.gc.ca/en/guidance/roadmap-migration-post-quantum-cryptography-government-canada-itsm40001 > > -----Original Message----- > From: Andrew Lee <[email protected]> > Sent: July 1, 2026 5:58 PM > To: Kevin Milner <[email protected]> > Cc: Nadim Kobeissi <[email protected]>; [email protected] > Subject: [TLS] Re: WG Last Call: draft-ietf-tls-mlkem-08 (Ends 2026-07-08) > > On Jul 1, 2026, at 2:22 PM, Kevin Milner <[email protected]> wrote: > > > several very widely deployed libraries and applications are already > implementing pure ML-KEM (I believe several have been cited previously in the > discussion of this draft, by both sides), and I suspect more will over time. > > > Do you happen to have a few examples or a link to this so-called wall of > shame? People have rolled their own libraries since the beginning. Just > because people are releasing things doesn't mean the IETF has to put their > name on everything with a meaningless RECOMMENDED=N. > > > > It’s important to separate opposition to the rollout of non-hybrid PQC > from opposition to this draft. > > > > Someone from the Canadian Centre for Cyber Security (Canadian Government) > literally wrote on list they are relying on this document to be published so > they can recommend solo ML-KEM [0][1], and an expert PQ cryptographer [2] > pointed this out in addition to their opposition. > > In RFCs, nobody reads the part where it’s recommended or not. If they open > the document, it’s because they’re looking for the implementation / protocol > details. An RFC signals adoption by the IETF outside the IETF, whether the > word “adopted” means _adopted_ here or not. > > > [0] Not surprising given the new C-22 spy bill. > [1] https://mailarchive.ietf.org/arch/msg/tls/uOeM5IRcYYjpNFlRyxEfo91q29c/ > [2] https://mailarchive.ietf.org/arch/msg/tls/oxuqWPQ08itms6NxEPCiFVzVgtY/ > > > _______________________________________________ > TLS mailing list -- [email protected] > To unsubscribe send an email to [email protected]
_______________________________________________ TLS mailing list -- [email protected] To unsubscribe send an email to [email protected]
