Daniel Apon wrote:
>That is, sometimes the significantly smaller bandwidth of Curve25519 based
>ciphertexts is inherently necessary for current systems.
Yes, the large sizes of ML-KEM and ML-DSA, along with the absence of NIKE, are
problematic, not only for space but also for many terrestrial constrained radio
networks. I prepared the following table for the upcoming LAKE interim meeting,
which shows the total number of bytes required for a mutually authenticated
Lightweight AKE with ephemeral key exchange. The figures assume that both
parties authenticate using the same method and that the credentials used for
mutual authentication are provided by reference.
+------------+-------------------+-------------------+------------------------------+
| Auth type | Mutual Auth alg | Key exchange alg | Total message sizes
(bytes) |
+------------+-------------------+-------------------+------------------------------+
| Signature | Ed25519 | X25519 | 200
|
| NIKE | X25519 | X25519 | 100
|
| PSK | PSK | X25519 | 100
|
+------------+-------------------+-------------------+------------------------------+
| Signature | ML-DSA-44 | ML-KEM-512 | 6500
|
| KEM | ML-KEM-512 | ML-KEM-512 | 3200
|
| PSK | PSK | ML-KEM-512 | 1600
|
+------------+-------------------+-------------------+------------------------------+
| KEM | DAWN-β-512 | DAWN-β-512 | 1900
|
| Signature | UOV Is | DAWN-β-512 | 1200
|
| PSK | PSK | DAWN-β-512 | 1000
|
| Signature | UOV Is | CSIDH-2048 | 750
|
| NIKE | CSIDH-2048 | CSIDH-2048 | 550
|
+------------+-------------------+-------------------+------------------------------+
PSKs are not an optimal solution, as key management is complex and often
fragile in practice. While NIST is making strong progress on more compact
post-quantum signatures, comparable advances in quantum-resistant key exchange
are also critical. With 2035 only nine years away, there is a clear need for a
similar standardization effort focused on smaller, more efficient post-quantum
key exchange mechanisms (both KEM and NIKE).
Cheers,
John Preuß Mattsson
From: Daniel Apon <[email protected]>
Date: Monday, 23 March 2026 at 19:53
To: Joseph Salowey <[email protected]>
Cc:
<[email protected]>
Subject: [TLS] Re: Status of ML-KEM WGLC
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 protected]<mailto:[email protected]>> wrote:
On Sun, Mar 22, 2026 at 11:04 AM Stephen Farrell
<[email protected]<mailto:[email protected]>> 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 protected]<mailto:[email protected]>
> To unsubscribe send an email to [email protected]<mailto:[email protected]>
_______________________________________________
TLS mailing list -- [email protected]<mailto:[email protected]>
To unsubscribe send an email to [email protected]<mailto:[email protected]>
On Mon, Mar 23, 2026 at 11:52 AM Joseph Salowey
<[email protected]<mailto:[email protected]>> wrote:
On Sun, Mar 22, 2026 at 11:04 AM Stephen Farrell
<[email protected]<mailto:[email protected]>> 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 protected]<mailto:[email protected]>
> To unsubscribe send an email to [email protected]<mailto:[email protected]>
_______________________________________________
TLS mailing list -- [email protected]<mailto:[email protected]>
To unsubscribe send an email to [email protected]<mailto:[email protected]>
_______________________________________________
TLS mailing list -- [email protected]
To unsubscribe send an email to [email protected]
