[TLS] Re: WG Last Call: draft-ietf-tls-mlkem-08 (Ends 2026-07-08)

[Andrew Lee <[e-mail]>]

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 <[e-mail]> wrote:
> 
> 
> 
> On Sun, Jul 5, 2026 at 9:55 AM Salz, Rich <rsalz=[e-mail] <mailto:[e-mail]>> wrote:
>> 
>> 
>> On 7/5/26, 12:33 PM, "Andrew Lee" <[e-mail] <mailto:[e-mail]>> 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 -- [e-mail] <mailto:[e-mail]>
>> To unsubscribe send an email to [e-mail] <mailto:[e-mail]>