Hi All, I'm going to split this letter into three parts; first, a discussion on the specific proposal at hand and concerns with its motivation; second, a general discussion about consensus in collaboration; and third, a series of objections regarding the proposal that attempt to illustrate exactly what my concerns are with adoption of this draft.
Please forgive me in advance if I messed up any citations or if there
are any factual errors. This is more of a brain-dump than a proper
essay, and the citations are moreso for illustration than to act as,
you know, citations.
----------------------------------------------------------------------
----------------------------------------------------------------------
The purpose of the revision was described as:
> Given this, the chairs will move the document back to the "WG Document"
> state and ask the author to work on resolving the issues brought up on the
> list including text to address concerns that there are reasons to prefer
> hybrid over the pure approach. [1]
... While the specific text that was added for motivation in this draft was:
+ Use cases include regulatory frameworks that require standalone post-quantum
+ key establishment, targeting smaller key sizes sizes or less computation,
+ and simplicity. [2]
+ ...
+ Hybrid mechanisms provide security as long as at
+ least one of the component algorithms remains unbroken, combining
+ quantum-resistant and traditional cryptographic assumptions.
+ Standalone ML-KEM relies on lattice-based and hash function
+ cryptographic assumptions for its security. [3]
This addition does not address any of the arguments/discussion for or
against hybrids. There has been a large body of counterarguments presented
for standalone adoption, and very little in the way of response to those
counterarguments. The purpose of this document cannot be cyclic
("the purpose of adding ML-KEM is to allow implementations of ML-KEM")
and must stand up to basic scrutiny.
I agree with many contributors here that ML-KEM is likely secure, and that
module lattice problems are likely as hard as general lattice problems.
However, accepting that fact without belief beyond a reasonable doubt
is bad risk management at best, especially with the increasing interest
in cryptanalysis against the underlying problems.
I've made a best-faith effort to enumerate potential motivations,
including those that have previously been brought up in the past few
months on this mailing list, and address why I believe they are not
suitable motivations for the purposes of addressing the concerns for
why a standalone should be preferred over a hybrid.
-> motivation: "Hybrids increase complexity."
TLS is a complex protocol. As we speak, there are active proposals
to increase the complexity by introducing new key renegotiation
protocols. The complexity introduced by a new addition must be
holistically balanced against the attack surface it introduces. Hybrids
introduce complexity alongside the value of confidentiality reducing
to two potentially hard problems, rather than just one; in essence
reducing the attack surface in exchange for a small increase in
complexity.
Today, all TLS implementations are virtually required to support
ECDH for compatibility reasons. Adding ML-KEM (as a hybrid or
otherwise) is an increase in complexity no matter what, as no one
will be able to drop ECDH for at least a decade or so. Only once
the hybrid has been widely adopted will implementations be ready
to begin dropping support for ECDH, at which point removing the
ECDH seatbelt solely for complexity/simplicity reasons would
become a more reasonable motivation.
-> motivation: "Hybrids have larger key sizes"
In the context of ML-KEM, arguments about key sizes really shouldn't
be an acceptable motivation. For ML-KEM 768, with a ciphertext of
1088 bytes, we are talking about a 2.9% increase in ciphertext size
and a 2.7% increase in key size for x25519. When we add in future
support for PQ signatures, this is going to become a drop in the
bucket. Middleboxes WILL need to raise to at least 9000 MTU, and
the small impact hybrids have will be meaningless no matter what.
-> motivation: "Hybrids increase cycle counts [over plain ML-KEM]"
Marginally. A full ML-KEM exchange takes about 33% of the cycles
for a full x25519 exchange, including key generation. The speedup
is on the order of microseconds, when we don't take into account
the extra memory/cache/bandwidth added by the larger size of ML-KEM
keys and ciphertexts, but we're still using microseconds as units
here. I don't think performance is a good measure of the practicality
of either scheme, as arguments can be made any which way.
Both are fast, and the motivation that one should be abandoned
because it is *marginally* slower by *one specific cherrypicked
measurement* is not a good motivation.
I can also pick measurements by which X25519 has higher merit than
ML-KEM, such as the observation that X25519 is easier to vectorize
2x1 to perform the same scalar multiplications on two different bases
at the same time. I can also make arguments about the increased
transcript, or the increased memory pressure for high-performance
servers. It's not productive to evaluating this draft to nit over
cycle counts that are insignificant when factored into the overall
performance of TLS; it's the same reason why we shouldn't be
counting cycles for AES-CCM vs AES-GCM to determine their merit.
I say this as someone that is very interested in the performance
of modern software: cycle counts are not a good measurement of
holistic performance in real-world scenarios.
-> motivation: "We eventually will need to adopt ML-KEM anyways"
This motivation does not discuss a reason why standalone should
be preferred over hybrids.
There is no telling which ciphersuites will end up best for post-
quantum adoption. The first call for post-quantum cryptosystems
was put out by NIST in 2016, with ML-KEM only being standardized
in 2024. Innovation of this scale is slow, and by the time CRCQs
are demonstrated to be on the horizon, we may have developed new,
stronger schemes or refined our understanding of the existing
proposals. We can afford to be patient before putting our full
trust in a cryptosystem.
The fact that we have the ability to do something today does not
imply that our hindsight tomorrow will be rosy. I would give the
exact same objection if we talked about dehybridizing HQC or BIKE:
it is still far too soon for us to properly predict how they will
perform against future cryptanalysis, despite some early good signs
in the form of a lack of progress on [11] and NP-completeness in [12].
The class of problem they use is independent from the hardness
of that problem. Kyber is to Frodo as HQC is to McEliece, and
similarity in some aspects does not imply a reduction. For example,
the Number Field Sieve allowed precomputing DLP on groups for attacks
on DH, but these attacks did not carry over to ECDH, despite the
many similarities between DLP and ECDLP.
-> motivation: "Lattices have been studied extensively."
This motivation does not discuss a reason why standalone should
be preferred over hybrids.
We are still only less than two decades past mainstream adoption of
ideal/module lattices, and there still exist many open questions
about the applicability of structure-driven heuristics. There
is still a notable lack of reduction between module lattices and
general lattices, which implies that we still do not understand
their structure enough to have full confidence that LWE and M-LWE
are as equivalent as it says on the tin. An example of a conservative
choice which is structured around well-studied problems is FrodoKEM,
which won't be adopted by this WG for many reasons (chiefly, the fact
that bandwidth costs are far too high).
Even the cutting edge of research on these structures broods uncertainty.
An early worst-to-average-case hardness came just a few months ago
in [4]. A new method of performing SVP using recursion was described
in 2025 [5]. The bounded-distance-decoding problem was attacked in [6].
While none of these papers demonstrate a real attack that breaks ML-KEM
by any means (and of course, [4] increases confidence), the pace and
novelty of recent research on lattices does not reflect that of a
'well studied problem'. It is clearly still a dynamic and interesting
field of research.
-> motivation: "Publishing offers a stable reference for the codepoints"
This motivation does not discuss a reason why standalone should
be preferred over hybrids.
I'm not sure there's really anything novel in the draft that
wouldn't be immediately obvious to someone implementing support
for the codepoint themselves. The document spends more time
discussing the potential footguns when integrating with TLS
(which I appreciate!!) than it spends actually discussing how
to integrate ML-KEM into TLS 1.3. For the most part, it's just a
copy of [ECDH-MLKEM] with references to ECDH removed.
Furthermore, if we are to publish this document solely as a stable
reference for vendors selling products to the government, then why
doesn't the government create their own copy of this standard and
distribute that within the context of their own vendor/client sales
discussion? Why does this need a sign-off from the IETF when the
scope of adoption is limited in this way, and clear alternatives to
standardization exist?
-> motivation: "Federal rulemaking should be adopted to support vendors."
This motivation does not discuss a reason why standalone should
be preferred over hybrids, unless we consider 'Uncle Sam said so'
as a reasonable motivation for doing something.
Federal rulemaking is inconsistent and is not always in the best
interest of the general public. For example, NIST required that
SLH-DSA increase signatures per key from 2^50 to 2^64, despite
SLH-DSA's unique properties that allow it to surpass this limit
with a minimal hit on security. This would also force TLS to use
these 2^64 signatures for the **conservative-choice** CA chain
signatures, despite 2^32 or even 2^16 parameter sets being readily
available for standardization, for the simple reason that no
government rulemaking supports it. It would additionally encourage
TLS to support LMS for NSA rulemaking, which is equivalent to
giving CAs a loaded gun and politely asking them to carefully
shoot themselves in the foot.
This is not to mention the various other government standards
that are not in the best interest of the TLS WG: ECDSA and DSA/DSS
utilizing ElGamal signatures rather than Schnorr signatures, with
user-provided nonces, is one such example.
From our perspective, federal rulemaking is an opaque and largely
undemocratic process designed to serve the best interest of the U.S.
government. It should have very little influence on a standardization
process designed to serve the best interests of the whole world.
-> motivation: "Some legacy components do not support fragmented
ClientHello messages"
I strongly believe this concern can be fixed by adopting X25519-
MLKEM512 for these kinds of use cases, as Facebook did internally.
I do not see why the X25519 component must be dropped in order to
accommodate these large ClientHellos, and I don't think the other
alternatives to approach this problem have been considered.
(Does MLKEM768 cause ClientHello fragmentation?? I'd think that
a typical ClientHello would be just small enough that MLKEM768
can fit in one packet, right? If it's an excessively large
cipher list, can that be cut down to prevent fragmentation?)
-> motivation: "IoT devices will not want to implement hybrids"
I find this claim dubious. Ultimately, if a device can afford
to perform a P-256 handshake, then X25519-MLKEM768 would be a
upgrade. I'd believe that any IoT device vendor that implements
P-256 ECDSA and ECDH would happily implement a hybrid with X25519.
Of course, many IoT vendors implement P-256, and happily eat the
performance issues of using the curve, so I don't think there
would be any pushback to a combination of two fast(er) primitives.
I would actually love to hear from someone who participates in
embedded TLS development. Personally, I don't expect any IoT
TLS implementations to drop ECDH, so pure ML-KEM would not be
a reduction in code complexity. Would hybridization actually
kill adoption of ML-KEM in constrained spaces, or would it just
leave a bad taste in implementer's mouths, or would it be
totally fine? I haven't heard any concrete arguments against
hybrid ML-KEM that are poised directly at adoption in IoT spaces.
-> motivation: "There is no harm adopting a spec only for the government"
-> and also, "The document will only be published as informational"
-> and also, "The document will be published with Recommended=N"
The reality is that any specification published by the TLS WG
should be assumed to be adopted by consumers indiscriminately.
We cannot skip the scrutiny for whether or not an addition is
secure for public use simply because it's conjectured that only
one customer will adopt it. Marking it as "Recommended=N" also
doesn't prevent adoption. P-521, for example, is still widely
deployed despite being Recommended=N, with there even being
a small racket when Chrome (rightfully!) dropped support [7].
In fact, googling secp256k1, another Recommended=N curve, quickly
gave me an article from wolfssl explaining how to use this curve
because of it's blockchain fame [8]. So no, Recommended=N and
'informational' are not reasonable arguments that the document
will not be adopted by users who don't (and shouldn't!) know any
better. Anything with the TLS/RFC rubber-stamp should be considered
as having the same level of merit to consumers.
Regardless, if we're saying that the document shouldn't be widely
adopted (Recommended=N and Informational) then... why are we going
to publish it? Wouldn't *not* publishing it send that message even
clearer?
> I can't stop people from shooting themselves in the foot but I don't
> want the WG to cause this.
> ...
> If I understand the email from Keegan correctly then we have a perfect
> example of the damage that this RFC can be causing as the Canadian
> government seems to be waiting for this RFC in order to recommend
> ditching hybrids in favor of fully exposed PQC. It's not hypothetical
> that people would ignore the = N, we have a stated intention on list.
> ~ Tanja Lange [9]
In order for this revision to pass the baseline criteria with which
it was commissioned, it would need to adequately describe why standalone
MLWE is not only acceptable, but needed RIGHT NOW, despite the current
deployment of hybrids.
I understand that this proposal does not have the benefit of having
a universally agreeable motivation. However, the TLS WG cannot treat
that as an excuse to allow a weak motivation to get lighter scrutiny.
As I've said previously, I can make a very compelling argument for
standardizing XChaCha8 or reviving the proposal to standardize 4Q,
but the motivation for making such a move must be evaluated in the
context of the existing ecosystem, which makes these proposals
irrelevant besides for a few niche use cases. In other words, *they
simply aren't competitive* in the grand scheme of things.
So, we're at a point where a small group of industry members are trying
to publish a specification that has no tractable motivation, arguing that
the document will not be widely used in the first place, in anticipation of
a future adoption that may never occur, for the purpose of compatibility
with a Recommended=N NamedGroup that (again!) shouldn't be widely implemented.
I see no reason why this spec should be adopted, even as Informational,
until one of the following becomes true:
- There is strong consensus that ML-KEM is the right pick for long-term
adoption, from all aspects of the information security community;
- Cryptanalysis gives us confidence beyond a reasonable doubt that
M-LWE is actually a hard problem;
- A practical* CRQC is realized, and it no longer makes sense to spend
the small amount of extra cycles on an elliptic-curve seatbelt.
* Key word is practical. Factoring 15 for the tenth time doesn't count.
All three of these conditions create a tractable motivation, and all
three should be years away at the very least. The codepoint has already
been registered, and vendors selling products to the U.S. government
are free to adopt it for their own products, but there should be no
mistaking that publishing an RFC, even Informational and with Recommended=N,
will prematurely declare ML-KEM a safe default ready for worldwide adoption.
Kurt Roeckx put it in a rather concise way:
> I'm also opposing this. There is no reason for this workgroup to get involved.
> We should only publish it if we think it's actually a good idea, and I've not
> seen anybody arguing that.
> ~ Kurt Roeckx [10]
The document should be sent back for revisions until it can provide
a reasonable motivation that describes why we should prefer a standalone
over the existing, widely-deployed, and unilaterally respected hybrids.
That might take years, and that's okay; we have time to be patient when
it comes to taking big risks.
[1] https://mailarchive.ietf.org/arch/msg/tls/Gc6KVPrVHn-QCkeEcvJ_qtRcFxY/
[2]
https://author-tools.ietf.org/iddiff?url1=draft-ietf-tls-mlkem-05&url2=draft-ietf-tls-mlkem-07&difftype=--html#diff0008
[3]
https://author-tools.ietf.org/iddiff?url1=draft-ietf-tls-mlkem-05&url2=draft-ietf-tls-mlkem-07&difftype=--html#diff0012
[4] https://arxiv.org/pdf/2511.13659
[5]
https://www.cs.cornell.edu/~speters/preprints/recursive-lattice-reduction.pdf
[6] https://eprint.iacr.org/2025/1910.pdf
[7] https://issues.chromium.org/issues/41168618
[8] https://www.wolfssl.com/using-secp256k1-with-wolfssl-a-step-by-step-guide/
[9] https://mailarchive.ietf.org/arch/msg/tls/oxuqWPQ08itms6NxEPCiFVzVgtY/
[10] https://mailarchive.ietf.org/arch/msg/tls/yMgyIaYKJ2qzhrPCw3y9CHYsS0E/
[11] https://decodingchallenge.org/
[12] https://eprint.iacr.org/2023/1064.pdf
----------------------------------------------------------------------
----------------------------------------------------------------------
Recently, there has been discussion on the list that implies consensus
is a majority rule. Consensus has never been achieved by vote or by
quantity of participation, but by the quality of structured debate.
Consensus is not a process by which we vote to accept or reject matters
at hand. Consensus is a process where we solicit objections and defenses
regarding a particular matter, and then evaluate their merit.
> Consensus on Wikipedia does not require unanimity ... nor is it the
> result of a vote.
> ...
> In determining consensus, consider the quality of the arguments, the
> history of how they came about, the objections of those who disagree,
> and existing policies and guidelines. The quality of an argument is
> more important than whether it represents a minority or a majority view.
> **The arguments "I just don't like it" and "I just like it" usually
> carry no weight whatsoever.**
> ...
> Consensus is ascertained by the quality of the arguments given on the
> various sides of an issue
> ~ Wikipedia:Consensus [WP:CON], Emphasis Mine
Don't just take my word for it; United States Federal law requires that
all objections be considered and responses to objections documented, as
a fundamental tenet of standards development activity.
> Consensus, which is defined as general agreement, but not necessarily
> unanimity, and includes a process for attempting to resolve objections
> by interested parties, **as long as all comments have been fairly considered,
> each objector is advised of the disposition of his or her objection(s)
> and the reasons why,** and the consensus body members are given an
> opportunity to change their votes after reviewing the comments.
> ~ Definition of 'Voluntary Consensus Standard' according to
> ~ 15 U.S.C § 4301 [VCS] [NIST-VCS], Emphasis Mine
Even within the IETF we acknowledge the idea that votes fail to address
the true purpose of consensus, which is to evaluate the merit of arguments
for or against adoption of a standard.
> If the chair finds, in their technical judgement, that the issue has
> truly been considered, and that the vast majority of the working group
> has come to the conclusion that the tradeoff is worth making, even in
> the face of continued objection from the person(s) who raised the issue,
> the chair can declare that the group has come to rough consensus.
> ...
> There are some times where chairs will ask a question or take a poll
> toward the end of a discussion in order to figure out the state of
> consensus, but this must be done with extreme caution.
> ...
> Because of this, using rough consensus avoids a major pitfall of a
> straight vote: If there is a minority of folks who have a valid
> technical objection, that objection must be dealt with before consensus
> can be declared. This also reveals one of the great strengths of using
> consensus over voting: It isn't possible to use "vote stuffing"
> (simply recruiting a large number of people to support a particular side,
> even people who have never participated in a working group or the IETF
> at all) to change the outcome of a consensus call.
> ~ On Consensus and Humming in the IETF [RFC7282]
I think it is clear that we will not reach consensus to adopt this draft.
For several months we have had outstanding objections for which no one
has adequately countered with a defense of the draft. This indicates that
the strength of arguments against adoption have more merit than those pro
adoption, and thus that consensus is against adopting this document.
I believe it would be far more productive to step away from the problem
of ML-KEM specifically and try to find consensus in the best way to
proceed in the overall realm of post-quantum adoption for TLS. There
are many more areas where a lack of such strong disagreement will allow
us to make real progress.
So far, the only denial-of-service regarding the working group is the
continued insistence that majority votes consist of consensus. They do
not; quality always trumps quantity.
[RFC7282] https://datatracker.ietf.org/doc/html/rfc7282
[VCS] https://obamawhitehouse.archives.gov/node/15059
[NIST-VCS]
https://www.nist.gov/system/files/documents/2025/09/17/circular_a-119_as_of_01-22-2016%20with%20background%20info.pdf
[WP:CON] https://en.wikipedia.org/wiki/WP:CON
----------------------------------------------------------------------
----------------------------------------------------------------------
I have several objections regarding adopting draft-ietf-tls-mlkem-* as
an informational document. These objections, when summed, present the
claim that standalone ML-KEM is not a competitive selection for inclusion
as a key exchange in TLS 1.3.
PREAMBLE
The bulk of my objection relies on the following arguments. These are
mostly refutations of existing points within the motivation and those
presented on the mailing list.
1. A complete abandonment of elliptic curve cryptography is not beneficial
for consumers or adopters, and creates a social justice issue.
Dehybridization does not decrease code complexity as long as ECDH
is still widely deployed and utilized.
It is a reality that, despite the widely agreed vulnerability to
a future cryptographically relevant quantum computer (CRQC), Elliptic
Curve Diffie-Hellman (ECDH) is still widely in use today. In order
to defend the confidentiality of information against a future CRQC,
we must perform a ramp-down of classical keyshare algorithms and
begin a ramp-up of quantum-secure keyshare algorithms. This is
a practically universally adopted requirement for future work on TLS.
ECDH ───────┐ ┌─────────── MLKEM
└─┐ ┌───┘░░░░░░░░░░░
└─┐ │░░░░░░░░░░░░░░░
└─┬┘░░░░░░░░░░░░░░░
ECDH │░░░░░░░MLKEM░░░░
Dominance ┌─┴┐░░░░Dominance░░
┌─┘░░│░░░░░░░░░░░░░░░
┌─┘░░░░└───┐░░░░░░░░░░░
MLKEM ───────┘░░░░░░░░░░└─────────── ECDH
▲ ▲
Adoption ─┘ └─ Adoption
Begins Complete
*Fig 1. Ideal Timeline of ECDH->MLKEM without transition period*
Fig 1 is one such timeline of adoption wherein standalone quantum-
secure algorithms are adopted (MLKEM) and ECDH is phased out. One
key requirement of this transition is that is requires implementers
to judge, independently, when it is acceptable to discontinue ECDH.
We will refer to the moment wherein we begin to adopt standalone
MLKEM as "Adoption Begin[ning]", and the moment by which the vast
majority of consumer-facing websites have migrated to MLKEM as
"Adoption Complete[d]". After this point, implementers will begin,
by their own logic, arbitrarily phasing out support for ECDH.
┌────┐
┌───┘ │
│ └─┐
┌┘ ▲ │
│ Phase ─┘ └┐
┌─┘ Out Begins │
┌─┘ └─── ECDH
┌─┘
ECDH ───────┘ ┌─────────── MLKEM
┌───┘░░░░░░░░░░░
│░░░░░░░░░░░░░░░
┌┘░░░░░░░░░░░░░░░
│░░░░░░░MLKEM░░░░
┌─┘░░░░░Dominance░░
┌─┘░░░░░░░░░░░░░░░░░░
┌─┘░░░░░░░░░░░░░░░░░░░░
MLKEM ───────┘░░░░░░░░░░░░░░░░░░░░░░
▲ ▲
Adoption ─┘ └─ Adoption
Begins Complete
*Fig 2. Cumulative graph of ECDH and MLKEM availability in TLS*
In other words, we will need to select a time at which old clients
which only support ECDH will need to be phased out. Chiefly, this
will become an armageddon of old devices: abandonment of ECDH will
effectively cut these devices off from modern service providers.
We see a similar pattern in the adoption of TLS 1.3 vs 1.2. Even
today, the vast majority of client and server implementations
support TLS 1.2, with Cloudflare reporting approximately 3% of
worldwide requests served with TLS 1.2. However, this data notably
has a sampling bias in that it records *requests* and does not
attempt to clarify visitors by e.g. utilizing visitor fingerprinting
technology. The reality is that the visitors with the least capable
hardware will be the ones utilizing the network the least, and as
such the ciphersuites supported by *visitors* is not adequately
measured by the ciphersuites supported by *each request*.
It is well established that socioeconomic status directly correlates
to not only electronic device access, but also the utilization and
capability of those electronic devices; see: The Digital Divide.
The consequences of forcing an abandonment of ECDH while many users
are still forced to use TLS 1.2 would disproportionately impact
those who either cannot afford new devices or aren't familiar with
modern computing. Chiefly, an abandonment of ECDH does not serve
these users, as any encryption is always better than no encryption
(except when "any encryption" provides a false sense of security,
such as is the case with some deceptive marketing practices).
While I understand social justice is outside of the realm of a
purely technical discussion, I do consider it an important part of
personal and scientific ethics to consider the consequences of
deciding that there *will* be a phase-out time for ECDH, similarly
to the discussion that would be had if the IETF decided that there
will be a phase-out period for TLS 1.2. Adoption of each protocol is,
ultimately, voluntary, and done out of each implementer's own
interest for compatibility.
Similarly to TLS 1.2, we may never truly be able to phase out ECDH.
Even supporting TLS 1.2 requires *not supporting post-quantum keys*,
so as long as TLS 1.2 stays, ECDH stays. We will probably see a
graph closer to this:
┌───────────┐
│ └─── ECDH
┌┘ ▲
│ Tiny dip ─┘
┌─┘ in support
┌─┘
┌─┘
ECDH ───────┘ ━ ━ ━ ━ ━ ━ ━ ━ ━ ━ ━
┌─────────────── MLKEM
│░░░░░░░░░░░░░░░
┌┘░░░░░░░░░░░░░░░
│░░░░░░MLKEM░░░░░
┌─┘░░░░Dominance?░░
┌─┘░░░░░░░░░░░░░░░░░░
┌─┘░░░░░░░░░░░░░░░░░░░░
MLKEM ───────┘░░░░░░░░░░░░░░░░░░░░░░
▲ ▲
Adoption ─┘ └─ Adoption
Begins Complete
*Fig 3. Cumulative adoption of ECDH and ML-KEM considering compatibility*
That is, that ML-KEM will be widely adopted, but not entirely, and
that ECDH will be required to support the minority of all remaining
servers and clients. With this established, we can use the following
logic:
- If ECDH must be implemented anyways (for the sake of compatibility),
then Hybridization will not increase code complexity over standalone
ML-KEM, as ML-KEM must be correctly implemented anyways.
- If Hybridization will not increase code complexity over standalones,
then Hybridization should be prioritized as a principle of risk
management in the event of cryptanalytic breakthroughs on ML-KEM
- It is easier to drop support for ECDH on the client than it is on
the server. At some point in the future, but not necessarily now,
standardizing standalone ML-KEM may provide small efficiency gains.
- Many clients will not be able to drop ECDH for compatibility
concerns, in a similar spirit to the first two points.
- It is easier to fully drop an ECDH implementation from TLS when
the implementer controls or is aware of the ciphersuites available
on all services that implementation will be used to connect to
(such as in embedded devices). At some point in the future, but not
necessarily now, standardizing standalone ML-KEM may reduce code
complexity in constrained scenarios.
- Adopting standalone ML-KEM will never reduce code complexity in
unconstrained scenarios. ECDH will be required for backwards
compatibility with old services.
Meanwhile, setting a fade-out date for ECDH, wherein major clients,
servers, and service providers collectively choose to drop ECDH,
will disproportionally impact those who cannot utilize ML-KEM, for
example if their device is out of support or newer software isn't
available/requires additional payment.
In summary, a future ramp-down of ECDH is difficult if not unethical.
It will have disproportionate impacts on older hardware/software and
require impacted users to downgrade to plaintext connections, which
are entirely worse than connections that are vulnerable to a CRQC.
Since a wind-down is difficult, arguments regarding code complexity
or a future complete abandonment of ECDH in implementations do not
stand up to scrutiny. ECDH will remain an integral part of TLS 1.3
whether or not we want it to, and we might as well benefit from the
increase in classical-attack assurance at the impact of a small
decrease in handshake throughput with hybridized handshakes. There
will likely never be a decrease in code complexity enjoyed by the
vast majority of clients or servers if we dehybridize ML-KEM.
2. Standalone ML-KEM is not yet a known hard lattice problem.
It has been a common statement and defense of the proposal to adopt
standalone ML-KEM that Module Learning With Errors (M-LWE) is a known
hard lattice problem. This is generally taken in the form of an
assumption that there is a reduction from M-LWE to solving SVP on
arbitrary lattices; this assumption is false. An attack on M-LWE
cannot, as of right now, be used to perform an "earth shattering"
speedup on general lattice problems.
The naming of M-LWE implies that it is similar in merit to LWE. This
confusion can also be seen in eg. the ECDLP problem vs. the plain DLP;
for example, the General Number Sieve attacks the DLP with a complex
pre-processing step but more efficient per-key attack phase. This
attack does not carry over to ECDLP or RSA, despite the presumed
similarity in the properties that make each problem hard.
This is not to say that we should immediately reject all asymmetric
cryptography solely by the merit that it does not have a reduction
to some other problem. I merely want to say that the common defense
of M-LWE, that is the defense that hard lattice problems have been
extensively studied, does not carry over from LWE to M-LWE.
> We analyze the hardness of Ring-LWE as an LWE problem, since, so
> far, the best known attacks do not make use of the ring structure...
> ~ NewHope
> ...
> The above mentioned algorithms do not use the ideal lattice structure,
> which means that they treat the R-LWE problem as a general LWE problem.
> This is common practice, since currently there is no attack on R-LWE
> that significantly improves upon the best known attacks on LWE for
> either a classical or a quantum computer.
> ~ [3]
3. Hybrids do not significantly increase latency vs standalone ML-KEM.
I agree that Standalone ML-KEM will improve throughput/latency by a
small, insignificant amount when compared to Hybrid alternatives.
However, Hybridization with ECDH will not bottleneck. Recently,
comparisons done in a laboratory setting showed a barely-measurable
difference between Kyber512 and the hybrid P-256/Kyber512 scheme within
the context of a TLS handshake; The non-hybrid required less CPU
time by a large margin (~200 microseconds in comparison to ~500
microseconds, which is close to some naive estimates) but that the
end result on the overall latency of the handshake was minimal:
1.78 milliseconds for Kyber512, compared to 1.81 milliseconds for
the P-256/Kyber512 hybrid [1]. Yes, that's about 30 microseconds of
difference in lab-measured latency. In Table 3 of [1], we see only a
~25% improvement in handshakes per second when we move from a P-256
hybrid to a standalone ML-KEM ciphersuite, this time on the order
of 300 microseconds, a bit closer to what we will probably see in
practice. Note that these numbers are for P-256/Kyber512, and not
the P-256/Kyber768 and X25519/Kyber768 hybrids that have been proposed
for TLS. I conjecture that the difference will be closer to 100us
in a X25519/Kyber768 hybrid.
In other words, I don't think utilizing a speedup on handshakes
where the unit of measurements is microseconds is a good way to
justify the adoption of a new algorithm. It will not cause an
observable latency increase for users, and will not present a
major bottleneck for high-performance server implementations.
> Moreover, the hybrid algorithms provided no performance downside on
> NIST level one. On higher levels, the PQ algorithms become faster
> than the hybrids (which have the pre-quantum algorithms as bottleneck)
> ~ [1] (Note: The performance drop at higher NIST levels is due to
> ~ the benchmarkers moving to P-384/P-521 at higher NIST levels)
4. Publication as Informational is Endorsement.
There has been a continued insistence that publication as informational,
and with "Recommended=N", is not an acceptable compromise for the
objection that the proposal constitutes premature endorsement of
ML-KEM. There are numerous, countless examples of times where an
informational publication, sometimes *independent* informational
publication, has been construed to be a recommendation from the TLS
Working Group.
One such example is the addition of GOST Ciphersuites in TLS 1.3.
RFC9367 adds four symmetric ciphersuites and seven signature schemes,
all of which are marked Recommended=N. Despite this, the Wikipedia
page happily cites these independent submissions as Secure [2],
and it would probably be hard for a reader unfamiliar with the IETF
to distinguish this from an endorsed document published by the TLS
Working Group. This is not to imply a problem with adopting ciphers
made in Russia, but to imply a problem with assuming that everyone
who reads the document will properly understand the intent of the
authors within the framework of the IETF bureaucracy.
In other words, I ask the WG to consider that the people who think
"military grade cryptography" is the best security possible will be
reading this publication, and the consequences that candid wording
might have on general interpretation.
OBJECTION #1: Standalone ML-KEM increases redundancy within TLS
I have argued in (1) that Elliptic Curve Cryptography is, despite
our need to address post-quantum confidentiality, a fundamental part
of TLS 1.3, and will continue to remain a fundamental part of older
editions of the TLS suite. I have also argued in (3) that removing
ECDH and effectively dehybridizing ML-KEM also offers a barely
notable benefit in terms of performance.
Therefore, we are left with the choice of how many options to
support. Full ECDH+MLKEM coverage yields us 12 configurations when
we consider the most frequently deployed curves, and so far we have
narrowed that down to X25519/P-256 with MLKEM-768, and P-384 with
MLKEM-1024. While some arguments have been made for adding X448 with
MLKEM-1024, and I believe they should be seriously considered given
how trivial the addition is, I do appreciate that the TLS WG has
come up with such a short list.
The decision to include MLKEM-512, MLKEM-768, and MLKEM-1024, and
adding them independently of any curve, then constitutes both a
duplication of the underlying security assumptions and duplication
of parameter sets for the purpose of enabling small tweaks. When
comparing MLKEM-1024 and eg P-384/MLKEM-1024, we see that they
share the new assumptions and share similar measures of performance
(1) and both share the new M-LWE security assumption, but drop the
existing ECDLP assumption. This is by all measures a tweak to the
protocol, and one that lowers security by an, at the moment, unknown
amount as cryptanalysis continues to fluctuate (3).
Such tweaks and redundancies were rightfully discouraged with the
intent of promoting a simple set of ciphers and keyshares that could
be entirely implemented by every implementation, each one a secure
default. It is hard to see how standalone ML-KEM fits into this
picture of nonredundancy given it is, for the most part, a subset
of the hybridized schemes, and dubiously a secure default at all.
X25519
┌─────────────────┐
│ │ MLKEM
│ EC ┌─────────┼─────────┐
│ DLP │ │ │
│ │ BOTH! │ M-LWE │
│ │ ▲ │ BDD │
└───────┼────┼────┘ │
│ │ │
└────┼──────────────┘
So │ ┌── Amazing!
cool! You are ◄┘
└────► here! ◄─ Wow!
▲
└─ Great!
*Fig 4. Summary of Objection #1*
OBJECTION #2: Standalone ML-KEM does not serve the interests of the
public, and may be contrary to the interests of the public.
Throughout the discussion to adopt, there have been undertones of
influence from the United States Government. This is natural; all
federal agencies perform their own internal rulemaking independently
of standards development organizations, and many times those rules
do not contradict the interests of the general public. However,
when it comes to information security, the best interests of the
general public far outweigh whatever interests each federal agency
may have in the TLS standardization process when they are at odds.
The best interests of the public, as far as the TLS WG should be
concerned, is ensuring the long-term confidentiality of TLS sessions,
and within that risk management framework we are guided to make
conservative choices regarding confidentiality. I have argued in
(2) MLKEM isn't a conservative choice of "lattice cryptography",
but instead earns the less-prestigious title of "structured lattice
cryptography". This is still absolutely an experimental field with
an evolving body of knowledge that will likely continue to grow
well into the next decade. It is poor risk management to accept
the positive signs from the initial stages of this cryptanalysis as
an indication that the scheme is secure, especially when it is hard
to even identify the scope of open questions published by each
successive analysis.
The motivation for hybridization is simple: In the worst case, the
confidentiality of information protected by hybridization relies on
our old assumptions; in the best case, it relies on the combination
of old and new assumptions. In other words, there is no risk with
accepting a hybridized ML-KEM, and thus we should be compelled to
adopt it. The key detail distinguishing standalone ML-KEM from the
hybridized variants is that standalone ML-KEM fully abandons our
existing, old assumptions, and thus puts all of our faith on the
new assumptions.
MLKEM ──┐ ~200 bits
-768 │
│
│
│
│
│ uh oh.
│
└─────────────────────────────────── ~0 bits
▲
└───── Coppersmith (2027)
*Fig 5. The Bad Ending.*
OBJECTION #2.5: Standalone ML-KEM *right now* does not serve the interests
of the general public, even if it will serve them in the future.
Specifically, it is difficult right now to measure the objective
security of ML-KEM against both the current attacks and the future
combinations of existing attacks. As such, it is difficult to
establish, from a risk management perspective, the slope with which
progress will follow, and estimate the plateau where cryptanalysis
will come to rest. In other words, we cannot say with confidence
whether or not MLKEM-768 will actually come to rest at 192 bits of
security, or if it will come to rest closer to 128 bits, for example.
Furthermore, as I have argued in (4), any publication of ML-KEM by
the TLS WG, regardless of how potent the warnings against footgunning,
will be interpreted as the TLS WG having full confidence in all
ML-KEM parameters settling at their original security assumptions,
and additionally will be interpreted as an endorsement for the uses
of the general public and commercial entities.
We do not want TLS to live in "interesting times" as far as the old
proverb goes. There is no reason not to adopt new assumptions, but
that cannot come at the cost of prematurely abandoning the old ones.
MLKEM ───┐ ~200 bits
-768 │
└─────┐ <long term stability>
▲ └──┐
│ ▲ └───────────────────────── ~190 bits
│ │ ▲
│ │ │
A new Minor
idea! refinements
*Fig 6. The Good Ending. We hope for it, but cannot guarantee it.*
When and if such a time comes in the future that we can confidently
determine the security of ML-KEM, and the TLS WG comes to such a
consensus, then it is absolutely time to adopt ML-KEM. Just because
that may happen in the future does not mean it is happening right
now, and does not mean that patience is pointless in this matter.
Again, no one is in a race to drop ECDH.
OBJECTION #3: Lack of publishing will not kneecap adoption of ML-KEM
within the context of vendor/customer relationships. The general public
does not have a need for stable definition of the codepoints.
This objection, admittedly, stands on shakier footing. While I try
to argue that the public's general interest is not for the adoption
of standalone ML-KEM in #2 and #2.5, there has also been interest
in publishing this document specifically for the purposes of having
a stable reference for the few souls who do find themselves forced
to implement standalone MLKEM within a vendor/customer relationship.
I will cede that it is completely beneficial for competition to
prevent incompatible TLS implementations from floating around.
This motivation requires extra fluff to defend against (4), which
in turn requires the WG to decide on exactly how strongly the anti-
footgunning provision should be worded. *This is not a good sign.*
Ultimately, my objection in this sense is that the TLS WG should not
publish a document that requires such extensive scorning. It would
require there to not only be a real market *specifically* for ML-KEM
inside TLS, and significant anti-footgunning wording; which indicates
that a document *isn't ready to be published* until the root causes
of that footgunning can be addressed. For dehybridization, the cause
is foundational and can't be removed. At the same time, the codes
have already been allocated, and there is nothing stopping vendors
from using them solely in pursuit of client/vendor relationships.
On the other hand, the contents of the dehybridization draft are
completely trivial. I can simply remove all mentions of ECDH from
[ECDH-MLKEM] and come to the same draft; that is not to say no effort
has been put into the draft, but that the only substantial content
of it is the security considerations that the author has put into
it, and there is little in the way of novel ideas for how to integrate
MLKEM. The only fear we should have with *not* adopting this document
is that someone chooses to add some pizzaz to their MLKEM implementation
such as having both the client and server exchanging public keys
rather than the client sending a public key and the server returning
a ciphertext. However, it is clear that such an implementation would
go against common sense as far as compatibility goes, especially
since there are already implementations of standalone MLKEM sitting
dormant, according to several members of this WG. I do not see
how an incompatible proliferation of TLS can occur when presumably
such vendor/client relationships will ensure compatibility with
existing implementations, all of which I would assume are currently
compatible with each other.
OBJECTION #4: ECDH still holds value until a CRQC is realized.
There is a statement and sentiment that ECDH is useless because of
the fact that sometime in the future a CRQC will be invented and,
of course, immediately put to work. However ECDH still holds value
in defending against classical attacks until an attacker puts in the
effort to put the thing through a quantum computer. That not only
depends on the time it takes to invent a good one, and the time it
takes for said good one to run. If it takes 5 years to invent a CRQC
capable of computing one ECDLP a week, then ECDH will hold value for
all but 52 ciphertexts per quantum computer per year. If it takes a
further 5 years to bring that number down to one ECDLP an hour, then
ECDH will hold value for all but 8760 ciphertexts per quantum computer
per year. If it takes a further 5 years to bring that number down to
one ECDLP a minute and then, well, we obviously have problems.
So, for five years, ECDH protected ciphertexts will still be valiantly
defended against from classical attacks. Then, for another five years,
the vast majority of ECDH protected ciphertexts will still be valiantly
defended against from classical attacks. That's ten years in which
we are able to say TLS wasn't broken, et cetera. That's ten years
over which the value of data protected by ECDH has depreciated and
potentially been obsoleted. Ten years of passwords getting reset,
ten years of secrets becoming public, and ultimately ten years of
much better ways to get your hands on the exact same information.
*ECDH is still better than nothing*. By no means ideal, and I think
we all agree about the importance of adopting quantum-secure TLS.
But even in the face of a complete break of MLKEM, ECDH holds value
in ensuring that data continues to depreciate at a rate at least
somewhat comparable to the rate at which quantum computers improve.
OBJECTION #5: Standalone MLKEM is not a competitive selection for TLS
I have argued that Standlone MLKEM does not reduce the complexity
of TLS implementations (1), that Standalone MLKEM is not really a
'conservative' choice (2), that dehybridizing MLKEM does not provide
a significant benefit to the performance of TLS (3), that Standalone
MLKEM is redundant in the context of TLS in #1, that adopting a non-
hybrid KEM is not only an unnacceptable risk in #2, but also strictly
reduces the long-term security of TLS in #4, and that we should be
patient in waiting for cryptanalysis to form a cohesive stance on
the security of ML-KEM before adoption in #2.5. Lastly, I argue that
the non-competitiveness of MLKEM is not outweighed by the desire for
compatible implementations in #3, and that adopting ML-KEM for this
purpose will send a false message that ML-KEM is actually competitive
in (4).
Standalone ML-KEM simply cannot compete with Hybridized ML-KEM when
we remove the pressure of government rulemaking, itself dubiously
pressuring vendors to prematurely declare MLKEM a competitive choice.
There is no reason to consider MLKEM a competitive choice as the
sole security measure for the entirety of the digital world's
encrypted traffic in the context of current advancements of hybrid
keyshares and the uncertainty of evolving cryptanalysis.
THAT BEING SAID I have several points of agreement with some members of
the WG and the defenders of this draft. For the sake of encouraging good
faith discussion I will enumerate some below:
- The immediate adoption of Quantum-Secure cryptography is an urgent
national security concern at an international level. It is imperative
as information security enthusiasts and advocates that we rapidly
enable the adoption of post-quantum cryptography.
- Hybridization is a secure way of adopting post-quantum cryptography,
and the urgent adoption of hybridized post-quantum primitives is the
most prudent way to ensure post-quantum cryptography is deployed.
- There is an argument to be made that publishing a document on ML-KEM
with ample anti-footgun-wording may have merit in fostering compatible
implementations among a very small minority of adopters. The document
will require changes to address any concerns in (1) (2) (3) (4) that
the WG considers to be legitimate issues regarding consensus, in
which case I will probably choose to support publication of the draft.
And of course,
- The best time to set X25519MLKEM768 as Recommended=Y was yesterday,
but the second best time is *right now*.
- ML-KEM is a well-designed cryptosystem that makes many bets on the
hardness of M-LWE. If those bets pay off, then they will have created
the obvious choice for post-quantum confidentiality. If consensus begins
to show confidence in M-LWE, regardless of if that is soon or far into
the future, standalone ML-KEM should absolutely be adopted as the future
of TLS key agreement.
To quote Wikipedia again, a lack of disagreement is more important than
agreement. I look forward to discussing these objections.
[1] https://dl.acm.org/doi/pdf/10.1145/3624354.3630585
[2] https://en.wikipedia.org/wiki/Transport_Layer_Security#Cipher
[3] https://eprint.iacr.org/2014/599.pdf
[4]
https://hal.science/hal-04028217/file/2022-12-01_hardness_mlwe_with_short_distributions_eprint_revised.pdf
----------------------------------------------------------------------
----------------------------------------------------------------------
I hope this letter helps set the WG back on track towards the long term
goal of ensuring post-quantum security of TLS, rather than trying to
rush premature standalone adoption without any clear benefit to the
general public.
Best,
Joshua Nabors.
On Friday, February 20th, 2026 at 7:01 AM, Paul Wouters
<[email protected]> wrote:
>
> [ AD hat on ]
>
> All,
>
> I want to remind people that the goal of this 2nd WGLC is to focus on
> the new text changed in responds to the conclusion of the 1st WGLC.
>
> We already had a WGLC on this document [1] and the conclusion [2] was
> that it passed WGLC provided some clarifying text would be added that
> stated that for the general use case, hybrids were preferred. This
> 2nd WGLC is about that topic.
>
> There is an appeal chain that got muddled by the inappropriate use of
> derivative clauses that is still in progress, but so far yielded the AD
> statement [3] that confirmed the WG Chairs view that the consensus call
> passed. There is an appeal with the IESG [4] on that decision, and this
> document will not be placed in the RFC Editor queue until that appeal has
> concluded, but will also not stop all processing while the appeal runs.
>
> This 2nd WGLC is meant to get those people who provisionally said "yes"
> to publication of this document pending some extra text, to review this
> text and let us know if that resolves the conditional part of their
> "yes" statement. The text changes to discuss can be seen at:
>
> https://author-tools.ietf.org/iddiff?url1=draft-ietf-tls-mlkem-05&url2=draft-ietf-tls-mlkem-07&difftype=--html
>
>
> I understand this is a heated topic. I am also not hearing from people
> that they have changed their opinion on whether or not to publish this
> document at all. Confirming your views are fine, but again, that is not
> the goal of this 2nd WGLC. It would be helpful if, especially those
> people who wanted additional clarifying text, to give us feedback on
> this. And ideally, offer up suggestions that would address any still
> outstanding issues.
>
> Thanks,
>
> Paul
>
> [1] https://mailarchive.ietf.org/arch/msg/tls/Pzdox1sDDG36q19PWDVPghsiyXA/
> [2] https://mailarchive.ietf.org/arch/msg/tls/Gc6KVPrVHn-QCkeEcvJ_qtRcFxY/
> [3] https://mailarchive.ietf.org/arch/msg/tls/dzPT8KQe4S-_pZROLUJMvS9pM0M/
> [4] https://datatracker.ietf.org/group/iesg/appeals/artifact/230
>
> _______________________________________________
> TLS mailing list -- [email protected]
> To unsubscribe send an email to [email protected]
>
signature.asc
Description: OpenPGP digital signature
_______________________________________________ TLS mailing list -- [email protected] To unsubscribe send an email to [email protected]
