I support publication of draft-ietf-tls-mlkem.
I agree that the announcement that the Canadian Centre for Cyber
Security plans to recommend use of ML-KEM (just as it will with
ECDHE-MLKEM) is not an indication that the RECOMMENDED=N flag is
meaningless. If the goal is to prevent any government agency or other
organization from recommending pure ML-KEM, then setting the
RECOMMENDED=N flag will not do this. But then, the IETF declining to
publish draft-ietf-tls-mlkem won't do that either.
While I understand why many people express a preference for hybrids, I
disagree with many of the arguments of those who insist that the
publication of draft-ietf-tls-mlkem must be stopped. While for most use
cases the additional overhead in terms of code, computation, and data
transmission of performing ECDHE-MLKEM rather than ML-KEM will not be a
problem, I do not believe that those who choose to use ML-KEM will be
"endangered."
While it is always possible that new cryptanalysis could break ML-KEM,
that is also the case for classical algorithms (such as RSA and ECDH).
ML-KEM is not a brand new algorithm based on a new hardness problem that
was introduced just a couple of years ago. It is closely related to
schemes that were developed well over twenty years ago, and
lattice-based cryptography has been studied extensively since then. We
cannot lump all PQC algorithms together. The breakage of SIKE says
nothing about the maturity level of ML-KEM. While I'm sure it was quite
a surprise when SIKE was broken in 2022, the report that NIST published
shortly before this break was announced (NIST IR 8413) said that "SIKE
seems promising but needs further study, as it is still a relatively new
scheme."
While one cannot rule out the possibility of implementation bugs, I
believe that others have well explained that it is far less likely that
there will be implementation bugs that are exploitable in an ephemeral
use case.
The code points for ML-KEM have been assigned and they are already
supported by multiple implementations. What what I can tell, the code
points will be specified in an RFC, it is just a question of whether
that RFC will be published through the IETF or as an independent
submission. Given that this is a good, secure option, useful for those
who do not want the overhead of having an implementation of ECDH, and
that there is running code, I believe it should be published through the
IETF.
On 7/5/26 20:34, Scott Fluhrer (sfluhrer) wrote:
I'm not exactly sure how this proves anything.
Presumably, the Canadian Government has access to first-rate
cryptographers, and they have decided that, for protecting internal
Canadian Government communications, that pure ML-KEM is sufficient, at
least in some cases.
Exactly how they came up with this conclusion, I cannot say (as I was
not involved). I would speculate that they may have decided that the
need for 'post Q-day' security was significant, and for that, hybrid
and pure ML-KEM are essentially equivalent.
Of course, other governments (with access to equally first-rate
cryptographers) have come to the opposite conclusion. What this would
indicate to me is perhaps the issue isn't quite as straight-forward as
the 'no' people are trying to portray it.
------------------------------------------------------------------------
*From:* Andrew Lee <[email protected]>
*Sent:* Sunday, July 5, 2026 12:32 PM
*To:* Hammell, Jonathan F - [he/il] <[email protected]>
*Cc:* Kevin Milner <[email protected]>; [email protected] <[email protected]>
*Subject:* [TLS] Re: WG Last Call: draft-ietf-tls-mlkem-08 (Ends
2026-07-08)
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]
_______________________________________________
TLS mailing list -- [email protected]
To unsubscribe send an email to [email protected]
