Subject: [TLS] Re: Status of ML-KEM WGLC
From: Daniel Apon <[email-masked]>
To: Joseph Salowey <[email-masked]>
Cc: "<[email-masked]>" <[email-masked]>
Date: Mon, 23 Mar 2026 14:52:20 -0400
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <tls.ietf.org>

Hello TLS WG and chairs,

I'd like to propose a renewal for the call for adoption of pure-mlkem (
https://datatracker.ietf.org/doc/draft-ietf-tls-mlkem/) as an RFC out of
the TLS WG.

This seems to move beyond Joe's recent comments here that the current
intent is to run a specific consensus call on the changed text (regarding,
by my understanding, the Motivation & Security Consideration sections of
https://datatracker.ietf.org/doc/draft-ietf-tls-mlkem/). Accordingly,
further context and explanation is needed for this message than a simple
in-line reply.

Many years ago, I was NIST's lattice cryptographer during the (now)
decade-long process of standardizing ML-KEM. I apologize for my late
arrival. I've watched the steps within the TLS working group from afar.
Admittedly, I have not been an active participant in the draft process for
pure-mlkem in IETF's TLS WG to this point. In terms of understanding the
way in which IETF works, I refer to RFC 7282,
https://datatracker.ietf.org/doc/html/rfc7282. I'm approaching this
discussion from that document, plus what I've seen in the TLS WG mailing
list discussion.

In the sense of RFC 7282, my previous position has been one of preemptive
capitulation. In other words, "Forget it; do what you want." In the words
of RFC 7282, this simply means "That's not coming to consensus; there still
exists an outstanding unaddressed objection." To wit, I notice that the
first session of the TLS WG at IETF 125 began with a recounting of a
mailing list ban of DJB, and an first-item-issue in the WG of an apology by
the chairs to DJB of accidentally censoring a message of his. Having spent
much time on the NIST PQC Forum over the prior years, I can easily imagine
the rough context of any such situation. (Who really wants to have a bitter
fight via email messages on an Internet forum?)

I am aware there was a recent "mandatory call" for pure-mlkem that recently
failed. It might surprise those who know me to hear that I agree with that
mandatory call failing. I do not think it's the proper time for pure-mlkem
to be mandatory.
Nonetheless, there is a distinct difference between a mandatory requirement
for ML-KEM and simply an official option for ML-KEM-only.

Currently, I represent a major vendor in the space of secure
communications. For our primary communications platform, we intend to offer
ML-KEM-only as the straightforward implementation of TLS for our systems,
at $100B+ scale. (I note a prior response in this thread indicates that
gmail is doing the same.)

That is not to say that we don't intend to have hybrid systems. In
particular, for many of our systems, we are actively exploring systems that
hybridize in an amortized way between ECC (e.g. X25519) and lattice-based
cryptography (ML-KEM-1024). That is, sometimes the significantly smaller
bandwidth of Curve25519 based ciphertexts is inherently necessary for
current systems.

So, this gets to my *main first objection* to the current state of
discussion (as held at the 125 meeting):

As a vendor, I believe both in the (current) security of X25519 and the
(long-term) security of ML-KEM, while being cognizant of the quantum threat
and HNDL. However, the efficiency profiles differ dramatically, and
different systems have different needs.
In contexts of challenging communication environments, we require the low
bandwidth of X25519 in order to have reliable communications.
Yet on the other hand, when considering a basic TLS-based system -- e.g. a
webserver connected to high-speed fiber with convenient access to a
reliable PKI, we believe that hybridizing between ECC+ML-KEM is the *worst
of both worlds.*

In particular, consider the performance profiles of these two schemes:
X25519 is noticeably slower to compute in parallel, while smaller in
bandwidth; ML-KEM is noticeably faster to compute in parallel, while higher
in bandwidth.
*In the most common/applicable use-case of TLS 1.3* -- i.e. high-bandwidth
traffic with millions of billions of connections, over reliable
infrastructure -- bandwidth is significantly less of a problem, and
computation constraints are the major concern.
Simply put, for TLS 1.3, pure-mlkem is the obviously correct solution if
you want high-performance solutions -- modulo security considerations
(let's turn to that now.)

My *second objection* to the state of the discussion regards the call for
CFRG/IRTF to render a fresh opinion on the cryptography of ML-KEM to the
TLS WG:

There has been a full decade of entirely open, international analysis and
debate over the security of quantum-resistant cryptography through the NIST
PQC process.
ML-KEM was fully vetted through this process (despite various detractors
that may feel otherwise).

Yet, the discussion in the TLS WG is not cryptographically detailed in the
nature. *No new cryptanalyses have been offered.* Just some grumbling.
Do we expect that a call to the CFRG will report something significantly
different in terms of number theory and computational analyses that NIST's
decade-long, international, open, and highly visible process did not? I
think that seems wildly unlikely.

My *third objection* to the discussion regards the talk of "Hard No"s to
prior WGLC's for pure-mlkem:

Certainly, there can be many "absolutely not!"s in the discussion of
whether to adopt this particular draft. However, that seems to run counter
to my understanding of  RFC 7282 in terms of the chairs' opinion on whether
rough consensus has been achieved. Again, I am not calling for a mandatory
use of ML-KEM-only; and indeed, I plan to use ECC in various systems (with
different performance constraints attached to them than the typical TLS
use-cases).

However, to /deny/ the option for ML-KEM-only to be used in TLS 1.3 would
seem to be a shocking repudiation of the decade-long, international effort
to that led to that cryptographic standard. Is it really an acceptable
outcome that a more visible, international process led to the
standardization /of the primitive,/ and yet -- in the most obvious use-case
in protocols (TLS 1.3 -- which has been the motivating protocol in every
lecture I've given in university grad courses for years now) -- it should
be fundamentally /disallowed/?

My *fourth objection*, following up:

At the 125 meeting, someone commented that "well, hey -- IETF standardized
the codepoints for ML-KEM. Isn't that enough?" No!
Many vendors will only support ML-KEM-only TLS if there is, specifically,
an RFC from IETF specifying such.
A very common goal in industry these days is to ensure "*no vendor-lock-in*"
for various products.
However, if this WG decides to disallow an RFC on ML-KEM-only TLS, then
many vendors will not produce products conforming to the natural outcome of
the NIST PQC process.

This would induce a punishing market effect on the broader vendor ecosystem
from a relatively obscure conversation in this WG's mailing list.

So, my general call is for the following:
1) Adopt hybrid-ECC-MLKEM for TLS 1.3
2) Adopt ML-KEM-only for TLS 1.3
2b) I strongly encourage neutral language in the RFC.
2c) "Proponents of hybrid" is not quite accurate, as there are not
"opponents of hybrid," but there *is* a significant vendor-community that
is *also* a proponent of ML-KEM-only, for specific systems.

Finally, I've had advice from a wise man who's active in this WG and many
others: "Don't come, fly over, and drop bombs, then never continue the
conversation again."
Understood! I'm happy to be here until the cows come home.
I also intend to share the (alarming) status of the current discussion with
others in the vendor community that want /an option/ for ML-KEM-only in TLS
1.3. This is *not* an effort to "ballot-stuff," but a genuine attempt to
make others aware that the conversation has gone so far here, without
sufficient representative input, that a standards/RFC outcome is near that
is entirely unexpected by many vendors.

Kind regards,
--Daniel Apon

On Mon, Mar 23, 2026 at 11:52 AM Joseph Salowey <[email-masked]> wrote:

>
>
> On Sun, Mar 22, 2026 at 11:04 AM Stephen Farrell <
> [email-masked]> wrote:
>
>>
>> Hi Joe,
>>
>> On 22/03/2026 17:49, Joseph Salowey wrote:
>> > ML-KEM WGLC Update
>> >
>> > We are working through issues brought up during the working group last
>> > call. We believe addressing these issues is necessary to determine if we
>> > have rough consensus to move forward. We expect the author to address
>> the
>> > following points:
>> >
>> > * Key Reuse
>> > * Text for preferring Hybrids
>> > * Whether to include motivations (see Liaison Statement)
>> >
>> > We expect resolving these issues will take a few weeks after which we
>> will
>> > run a targeted consensus call to see if text changes are acceptable to
>> the
>> > working group.
>>
>> The above seems to me unclear and hard to understand.
>>
>> Are you saying that the 2nd WGLC failed due to a lack of rough
>> consensus? (Or not?)
>>
>>
> [Joe] The chairs have determined that there is no rough consensus, but
> people have requested changes.  The chairs have asked the author to see if
> changes to the draft make a difference.
>
>
>> Either way, I don't know what you mean by a "targeted consensus
>> call" - if the 2nd WGLC failed, then surely another WGLC will be
>> needed or the draft is just stalled. If the 2nd WGLC succeeded,
>> then (that'd be a surprise and) I don't get why some other consensus
>> call would be needed, nor for what.
>>
>>
> [Joe]  The intent here is to run a specific consensus call on the changed
> text.  If you suggested changes in the draft in the previous WGLCs then we
> ask you to review and state whether the changes have helped (or not).  If
> you did not recommend changes, then your position will remain the same,
> unless you state that you are reconsidering.
>
>
>> So I'm confused, sorry.
>>
>> I do get that sometimes the result of a WGLC is "go ahead after
>> fixing these nits" but I don't see how that applies in a situation
>> with the fairly fundamental controversies we've seen related to
>> this draft.
>>
>> Cheers,
>> S.
>>
>>
>>
>> > Thanks,
>> >
>> > Sean and Joe
>> >
>> >
>> > _______________________________________________
>> > TLS mailing list -- [email-masked]
>> > To unsubscribe send an email to [email-masked]
>>
>> _______________________________________________
> TLS mailing list -- [email-masked]
> To unsubscribe send an email to [email-masked]

On Mon, Mar 23, 2026 at 11:52 AM Joseph Salowey <[email-masked]> wrote:

>
>
> On Sun, Mar 22, 2026 at 11:04 AM Stephen Farrell <
> [email-masked]> wrote:
>
>>
>> Hi Joe,
>>
>> On 22/03/2026 17:49, Joseph Salowey wrote:
>> > ML-KEM WGLC Update
>> >
>> > We are working through issues brought up during the working group last
>> > call. We believe addressing these issues is necessary to determine if we
>> > have rough consensus to move forward. We expect the author to address
>> the
>> > following points:
>> >
>> > * Key Reuse
>> > * Text for preferring Hybrids
>> > * Whether to include motivations (see Liaison Statement)
>> >
>> > We expect resolving these issues will take a few weeks after which we
>> will
>> > run a targeted consensus call to see if text changes are acceptable to
>> the
>> > working group.
>>
>> The above seems to me unclear and hard to understand.
>>
>> Are you saying that the 2nd WGLC failed due to a lack of rough
>> consensus? (Or not?)
>>
>>
> [Joe] The chairs have determined that there is no rough consensus, but
> people have requested changes.  The chairs have asked the author to see if
> changes to the draft make a difference.
>
>
>> Either way, I don't know what you mean by a "targeted consensus
>> call" - if the 2nd WGLC failed, then surely another WGLC will be
>> needed or the draft is just stalled. If the 2nd WGLC succeeded,
>> then (that'd be a surprise and) I don't get why some other consensus
>> call would be needed, nor for what.
>>
>>
> [Joe]  The intent here is to run a specific consensus call on the changed
> text.  If you suggested changes in the draft in the previous WGLCs then we
> ask you to review and state whether the changes have helped (or not).  If
> you did not recommend changes, then your position will remain the same,
> unless you state that you are reconsidering.
>
>
>> So I'm confused, sorry.
>>
>> I do get that sometimes the result of a WGLC is "go ahead after
>> fixing these nits" but I don't see how that applies in a situation
>> with the fairly fundamental controversies we've seen related to
>> this draft.
>>
>> Cheers,
>> S.
>>
>>
>>
>> > Thanks,
>> >
>> > Sean and Joe
>> >
>> >
>> > _______________________________________________
>> > TLS mailing list -- [email-masked]
>> > To unsubscribe send an email to [email-masked]
>>
>> _______________________________________________
> TLS mailing list -- [email-masked]
> To unsubscribe send an email to [email-masked]
>