I assume that most participants in this discussion have read Sophie Schmieg’s https://keymaterial.net/2025/11/27/ml-kem-mythbusting/ which among other things explains why intelligence agencies might like to use ML-KEM; their reasons include a common existing policy of double-encryption of highly-sensitive material. Personally I’m a fan of hybrid encryption and apparently so are these people, where one leg of the hybrid is ML-KEM and the other leg they’re not going to tell us about. I can see why they’d want a stable spec. Tbh this is the only convincing use-case I’ve heard for pure PQC, but it’s not a terrible one. -Tim
On Jul 5, 2026 at 10:58:13 AM, 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 <rsalz= > [email protected]> wrote: > >> >> >> On 7/5/26, 12:33 PM, "Andrew Lee" <[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] >> To unsubscribe send an email to [email protected] >> > > _______________________________________________ > 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]
