Hi Andrew, I think I understand your confusion now, thank you for elaborating. Please correct me if I’m wrong, but I believe you are interpreting the following facts: 1. The Canadian Centre for Cyber Security will recommend pure ML-KEM 2. The Canadian Centre for Cyber Security does not care if an eventual RFC includes Recommended=N to mean that Recommended=N does not have value.
I think I can clear this up, though. Both 1) and 2) are true because the Canadian Centre for Cyber Security has no reason to particularly care whether the IETF has stated Recommended=N, they set their own recommendations independent of the IETF. Similarly, I am assuming their recommendation would not change if the IETF has no RFC at all (if they are similar to other national bodies). The IETF does not have sovereignty over national agencies, and whether there is an RFC for pure ML-KEM almost certainly has no bearing on their recommendations in the same way the Recommended=N in the RFC has no bearing on their recommendations. If your argument is that Recommended=N is insufficient to prevent The Canadian Centre from Cyber Security from recommending pure ML-KEM, then the exact argument holds that voting no on this draft is insufficient. This would, I think, indicate this specific argument has no relevance to the current last call. But, for what it’s worth, the Recommended=N in the draft is not directed at the Canadian Centre for Cyber Security! We have no control over them, after all. It is aimed to be an IETF recommendation, as Eric explained, for everyone else. If you believe that publishing no guidance on usage of pure ML-KEM is better than publishing guidance against the usage of ML-KEM, that is fine, but I think you might be mistaken on the relevance of Jonathan’s comments to the current last call. Cheers, Kevin > On 5 Jul 2026, at 18:58, Andrew Lee <[email protected]> wrote: > > Dear Eric, > > For starters, the Canadian Centre for Cyber Security is not "some set of > entities." It is a Five Eyes government cybersecurity agency who has a > massive impact on an entire nation's infrastructure. > > They told this mailing list they will treat N the same as Y which is policy > affecting millions of systems and people therewith. > > That said, let me now address a deeper problem for those who support > publishing a draft on solo ML-KEM, because I believe a paradox has emerged > from the arguments made by yourself and Eliot in defense of the N flag, and I > thank you for bringing it to light. > > > 1. If there is no consensus to publish, which is the opposition's position > and which Eliot appears to lean on as the reason for the N, then the document > should not be published at all. > > 2. If the chairs determine there IS consensus and publish the RFC, then it > will have gone through 3 WGLCs and also a full IESG review. At that point, > "the item has not been evaluated by the IETF" becomes impossible. > > 3. The N can then only derive from the limited applicability or specific use > cases booleans. > > To be clear, Canada has told us on this list they will disregard that > distinction, even though the flag fails under both outcomes. > > If no consensus, publication is obviously unjustified. > > If consensus, the N cannot mean "not evaluated," leaving only the reasons > Canada plans to ignore. > > Chairs, I hope you can understand that publishing this draft will essentially > turn the IETF's rulesets into a hodgepodge of contradictions in addition to > the other dangers already documented within the IETF by the foremost > cryptographic experts. > > I rest my case. > > Best, > Andrew > >> On Jul 5, 2026, at 10:32 AM, Eric Rescorla <[email protected]> wrote: >> >> >> >> On Sun, Jul 5, 2026 at 9:55 AM Salz, Rich <[email protected] >> <mailto:[email protected]>> wrote: >>> >>> >>> On 7/5/26, 12:33 PM, "Andrew Lee" <[email protected] >>> <mailto:[email protected]>> wrote: >>> 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. >>> >>> You misunderstand what RECOMMENDED=N means. Quoting from an actual >>> registry[1] >>> >>> If the "Recommended" column is set to "N", it does not necessarily >>> mean that it is flawed; rather, it indicates that the item either >>> has not been through the IETF consensus process, has limited >>> applicability, or is intended only for specific use cases. … >> >> Note that it in 8447-bis this reads: >> >> Indicates that the item has not been evaluated by the IETF and that the IETF >> has made no statement about the suitability of the associated mechanism. >> This does not necessarily mean that the mechanism is flawed, only that no >> consensus exists. The IETF might have consensus to leave an items marked as >> "N" on the basis of its having limited applicability or usage constraints. >> >> This seems like it would be a fairly accurate description of the situation >> around this draft. >> >> -Ekr >> >> >>> >>> This is exactly what Jonathan is saying: >>> Therefore, our general guidance is not recommending one over the >>> other, as it may be a use case specific decision. >>> >>> [1] >>> https://www.iana.org/assignments/tls-extensiontype-values/tls-extensiontype-values.xhtml >>> >>> _______________________________________________ >>> TLS mailing list -- [email protected] <mailto:[email protected]> >>> To unsubscribe send an email to [email protected] >>> <mailto:[email protected]> >
_______________________________________________ TLS mailing list -- [email protected] To unsubscribe send an email to [email protected]
