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 < [email protected]> 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 >
_______________________________________________ TLS mailing list -- [email protected] To unsubscribe send an email to [email protected]
