[ 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
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ TLS mailing list -- [email protected] To unsubscribe send an email to [email protected]
