[TLS] Re: New Liaison Statement, "Liaison communication to IETF regarding draft-ietf-tls-mlkem"

[Daniel Apon <[e-mail]>]

Responding to Usama's message (which Usama quoted to Uri, in response to
Uri's question about whether Usama had answered my (Daniel's) question):

First, thank you Usama for pointing me to the proper text off-list, so that
I didn't mis-quote the context!
Let me try to go through this point by point [[Standard apologies for
length]]:



"On 06.04.26 02:16, Daniel Apon wrote:

I remember, and enjoyed, your talk slides about an abacus and a dog.

[Usama wrote:] Could someone please share a pointer to slides?"

Sure!
I'm not sure if there are multiple versions, but here is one I found (now)
from Peter Gutmann's academic website:
https://www.cs.auckland.ac.nz/~pgut001/pubs/bollocks.pdf
The relevant material is also encapsulated in an ePrint PDF (with status
"Preprint") at: https://eprint.iacr.org/2025/1237.pdf

Going through the details of that presentation is mostly off-topic, other
than I'd like to point out (since Uri asked Usama "whose expert opinion,
beside Dr. Bernstein's, are you willing to accept?") that apparently Dr.
Bernstein and I agree on at least one significant point here. See
https://en.wikipedia.org/wiki/Scientific_wager with:
"In 2023, John Preuß Mattsson bet $2,050 that [RSA-2048] will withstand
quantum computing until at least 2050. Daniel J. Bernstein, John Sahhar,
Daniel Apon, and Michele Mosca accepted the bet.[cf.
https://groups.google.com/a/list.nist.gov/g/pqc-forum/c/dezGXaKNNlU ]"

What fun. :) Back to the thread:


=====


"On 06.04.26 02:16, Daniel Apon wrote:

Also, I suppose "the middle distance" is Google's 2029 deadline now.

[Usama wrote:] That seems a little off-topic. Google's 2029 deadline is an
internal corporate roadmap and does not seem technically relevant to this
LS or the IEEE 802.11bt project."


It is fairly significant in the real world, and therefore, I believe,
on-topic: Google's adoption of this or that cryptographic technology
influences an immense & overwhelming amount of Internet traffic.
Indeed, when Google swapped to ECC by default in 2013, it constituted
something like 80%+ of the global adoption of ECC as a cryptographic
technology (over, previously, RSA).


=====


Continuing, Usama writes:

"IEEE 802.11bt project mentioned in the LS states

As an example, the United States National Institute of Science and
Technology (NIST) will disallow use of key establishment and digital
signatures based on classic cryptography for use in US government systems
after 2035.

Motion TGbt-M-16 [4] that is approved at IEEE 802.11 and that resulted in
this LS also has no such urgency as Google's 2029. As noted in [
https://www.ieee802.org/11/Reports/tgbt_update.htm ], the relevant
regulatory deadline (NIST) is 2035."


Well, first, NIST's instruction was written before the recent advances by
Google Research. Moreover, the deadline that NIST is stating (cf. original
source https://nvlpubs.nist.gov/nistpubs/ir/2024/NIST.IR.8547.ipd.pdf
from *November
2024*) should be viewed in context as the final deadline for the final
adopters. It certainly is not the expected timeline for most adopters, and
surely NIST may want to review that timeline and revise it based on new
information (now 18 months later) at their discretion.

The slowest adopters in the world will be the
least-cryptographically-relevant U.S. Federal bureau -- someone like the
USDA Forest Service, who is responsible for managing 193 acres of national
forests, with little attention (or need for attention) to cybersecurity in
their remit. (My sincere apologies to all of the honorable and faithful
Forest Service employees who read this thread; I really didn't mean to pick
on you.)

So, my basic point remains: If Google is transitioning to PQC with a
deadline of 2029, then that will constitute a Very Large Fraction of the
world's communications, particularly over TLS. It makes it a reasonable
timeline to frame the discussion.


=====


More to the essence of my reply, there are two points I'd like to make.

First, Usama writes:

" I sense no urgency in the LS. A publication within two years seems
aligned with their timeline [
https://mentor.ieee.org/802.11/dcn/26/11-26-0683-00bt-tgbt-march-2026-closing-report.pptx
]."

Indeed, it seems that IEEE 802.11 has set approximately two years for their
closing (as of their November 2025 document here).
It seems what I was referencing was, in fact, John Preuß Mattsson's comment
about
https://www.3gpp.org/ftp/tsg_sa/WG3_Security/TSGS3_127_Malta/Docs/S3-261117.zip
from 3GPP TSG-SA3 earlier in this thread.
So, I retract my statement that "IEEE is asking TLS WG to 'please hurry
up'" -- instead, it should be that 3GPP SA3 from ETSI finds relying on
numbered internet-drafts insufficient in place of an RFC.
In particular, it's a concern regarding
https://www.ietf.org/archive/id/draft-barnes-tls-this-could-have-been-an-email-00.txt,
where I happen to agree with the introduction there:

 "There used to be a grand tradition of debating the merits of
   cryptographic algorithms in the TLS working group.  Over time, folks
   realized that this was not a productive use of the WG's time.  The
   typical TLS WG participant is not a cryptographer, and the
   cryptographic choices of TLS users are typically dictated by other
   factors than the opinion of the TLS WG."

and yet also -- alongside 3GPP SA3 -- disagree with the conclusion that
RFC's ought not be published. Publishing an RFC matters; it's only a real
output once an RFC is finalized. (Yes, I understand other points in this
thread that the current discussion is on Type XYZ of an RFC vs Type ABC of
an RFC.)

That said, if the goal here is in fact to say "We'll get to a
pure-mlkem actual-RFC in two years, or something," (matching the IEEE
802.11 timeline, let's say) then shouldn't that *explicit timeline* also be
present even in an Informational RFC (or whatever Type XYZ of RFC that
finalizes [I'm ignoring my personal wishes here])?


=====


Second/finally, Usama writes:

"The topic under discussion is IEEE 802.11 LS for pure ML-KEM in the TLS
protocol. I think we must distinguish between algorithm standardization
(NIST) and protocol integration (IETF). While there is support for ML-KEM
as an algorithm, I am not aware of any "international consensus" on its use
as a pure KEM within the TLS protocol. If I have missed something, please
point me to any such "international consensus"."

I appreciate your agreement that there is international consensus for
ML-KEM as an algorithm. However, I also believe that requiring me to
further claim international consensus for "pure ML-KEM" is, genuinely, a
false dichotomy.

In my own company's systems, I have situations where I'd prefer to use pure
ML-KEM, and I have situations where I'd like to use a mix of ECC and
ML-KEM. Primarily, the advantage of the latter is for bandwidth savings in
highly signals-constrained environments. Working in only ML-KEM, in live
systems, comes with a much higher engineering burden than non-cryptographic
network engineers are happy to tolerate. (I'm also starkly aware that ECC
may be "dead" from a product engineering point of view, no matter what we
discuss here -- in that it may take years to roll out new ECC-based
products, and the lifetime of such protections may be very short these
days.)

Let's be clear about where we are: We have a passed-vote for RFC on
hybrid-TLS. Recently, we have, approximately, a couple dozen votes to
advance pure ML-KEM as another option; and another couple dozen votes to
forbid pure ML-KEM as another option. This isn't about requiring everyone
to use pure ML-KEM; this is only about whether some substantial
approximate-half of the body politic is permitted to use pure ML-KEM in the
TLS protocol at all.

Moreover, as I hinted at above, it should be clear that -- eventually --
pure ML-KEM *will* be the only viable choice (sans some kind of longer-term
additional international consensus about a new PQ-KEM algorithm standard,
which seems very far from coming). So, it's not even a question --
currently -- of whether pure ML-KEM will or won't be standardized; it can
only be a question of *when* pure ML-KEM will be standardized for use in
TLS.

So the basic framing of this question *should* be: Are all products and
companies and implementations *required* to support only hybrid-mode TLS
now, and also *required* to perform a second large-scale engineering effort
to migrate to pure ML-KEM sometime later (whenever that happens; and bless
everyone for having the energy to restart the conversation in two years or
whenever); *OR*, is it acceptable for early-movers to adopt a purely
quantum-resistant solution now, and offer it (optionally) to connections
that accept that algorithm suite during TLS negotiation?


Kind regards,
--Daniel


On Mon, Apr 6, 2026 at 9:11 AM Muhammad Usama Sardar <
[e-mail]> wrote:

> [ sorry for the length ]
>
> TL;DR: Those who know me understand that whenever I make strong claims, I
> later provide an independently reproducible proof behind my pushback, e.g.,
> proof [0] for claims [1]. I am doing my research on this ML-KEM thingy and
> I will present substantial evidence in Vienna. So thanks for your patience.
> If that is too late, can someone please explain genuine urgency so that I
> can prioritize it? Also, as a counter-argument to my position, can someone
> kindly show me that pure ML-KEM is *more* secure than hybrid in the
> context of TLS protocol? Thank you.
>
> Hi Daniel and Uri,
>
> I appreciate you raising concerns on my position. To ensure full
> transparency within the WG, I believe it is necessary to highlight the real
> context behind the development of this LS. The technical presentation [2]
> in IEEE 802.11 meeting in March that led to this LS states:
>
> > The IETF is seeking statements of support from other SDOs regarding the
> use of pure ML-KEM and the applicability of draft-ietf-tls-mlkem.
>
> It is the IETF who requested it, not the other way around. It further
> states [2]:
>
> > During the most recent call [3], Paul Wouters (one of the Security Area
> directors) noted that it would be helpful if IEEE 802.11 could send a
> liaison statement to the IETF saying that IEEE 802.11bt is pursuing use of
> pure ML-KEM. Following that call, I received clarification that
> specifically, a statement of support for draft-ietf-tls-mlkem [1] as being
> useful to IEEE 802.11bt would do the trick. Such statements will help show
> consensus for publication during WGLC.
>
> (Note: [1] and [3] in this quote are from original source. They don't
> match my references.)
>
> Soliciting an LS to "do the trick" for showing consensus does not address
> the technical concerns of two dozen people who have opposed publication in
> the WGLC. Given that *there is no public evidence of IEEE 802.11bt having
> consensus on using pure ML-KEM in TLS protocol*, isn't it fair to ask for
> technical rationale?
>
>
> On 06.04.26 02:16, Daniel Apon wrote:
>
> I remember, and enjoyed, your talk slides about an abacus and a dog.
>
> Could someone please share a pointer to slides?
>
> Also, I suppose "the middle distance" is Google's 2029 deadline now.
>
> That seems a little off-topic. Google's 2029 deadline is an internal
> corporate roadmap and does not seem *technically* relevant to this LS or
> the IEEE 802.11bt project. IEEE 802.11bt project mentioned in the LS states
> [3]:
>
> As an example, the United States National Institute of Science and
> Technology (NIST) will disallow use of key establishment and digital
> signatures based on classic cryptography for use in US government systems
> after 2035.
>
> Motion TGbt-M-16 [4] that is approved at IEEE 802.11 and that resulted in
> this LS also has no such urgency as Google's 2029. As noted in [3], the
> relevant regulatory deadline (NIST) is 2035.
>
> Besides, I don't think it should really matter to Google whether IETF or
> IEEE is publishing it. If it does, please explain in full detail to me.
>
> In any case, Richard's argument upstream seems to hold here as well: That
> should be their (Google's) issue, not ours.
>
>
> Let me turn to a more important point (or, points) by Usama in this thread:
>
> I am humbled that you consider my point(s) as 'important'. Hopefully the
> following clarifications will be help clarify my position.
>
> "IMHO, unless some technical rationale is provided by IEEE 802.11, this LS
> should just be read as 'someone somewhere in the world would like to use
> pure ML-KEM' and TLS WG should not serve as a *printing press* for such
> requests."
>
> I would like to clarify that you are half-quoting me. In particular, the
> following points in the same paragraph were stating that we should give
> them 'no objection response' to publish it to put an end to whole of this
> debate. I have also provided a way forward in TLS WG. So I am neither
> blocking IEEE nor TLS WG. Please don't make it sound otherwise.
>
> I completely disagree with the characterization that  'someone somewhere
> in the world would like to use pure ML-KEM.' It's dismissive of the current
> situation.
> Not only has the international community, after more than a decade of
> work,  aligned on ML-KEM as the PQ-KEM standard, but IEEE (as a computer
> scientist, IEEE is not no one!) is requesting that the TLS WG "please stop
> delaying."
>
> I respect your opinion but in my reading, it just says we support
> publication. Motion TGbt-M-16 [4] does not state anything about "delay". So
> I sense no urgency in the LS. A publication within two years seems aligned
> with their timeline [5].
>
> Even further up the thread, Usama writes:
>
> "I was actually hoping to see some *technical rationale* for support of
> publication."
>
> May I please point you to
> https://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.203.pdf
> or
> https://csrc.nist.gov/Projects/post-quantum-cryptography/email-list
> for overwhelmingly sufficient technical rationale?
>
>
> If the international consensus on ML-KEM as the post-quantum KEM standard
> is insufficient, would you please explain further what you explicitly
> desire in terms of *technical rationale*?
>
> The topic under discussion is IEEE 802.11 LS for pure ML-KEM in the TLS
> protocol. I think we must distinguish between algorithm standardization
> (NIST) and protocol integration (IETF). While there is support for ML-KEM
> as an algorithm, I am not aware of any "international consensus" on its use
> as a pure KEM within the TLS protocol. If I have missed something, please
> point me to any such "international consensus".
>
> Besides, I have asked for their technical rationale for the support in the
> context of their project IEEE 802.11bt mentioned in LS.
>
> Best regards,
>
> -Usama
>
>
> [0] https://github.com/CCC-Attestation/formal-spec-id-crisis
>
> [1] https://mailarchive.ietf.org/arch/msg/tls/Jx_yPoYWMIKaqXmPsytKZBDq23o/
>
> [2]
> https://mentor.ieee.org/802.11/dcn/26/11-26-0652-00-00bt-ietf-request-for-pure-ml-kem-liaison.pptx
> (Slide 2,3)
>
> [3] https://www.ieee802.org/11/Reports/tgbt_update.htm
>
> [4]
> https://mentor.ieee.org/802.11/dcn/26/11-26-0299-00bt-tgbt-agenda-2026-march-plenary.pptx
> (Slide 25)
>
> [5]
> https://mentor.ieee.org/802.11/dcn/26/11-26-0683-00bt-tgbt-march-2026-closing-report.pptx
>