P.S. Let me make explicit my subtext behind that final question/discussion above:
It really does matter *to me* whether transitioning to PQC happens (now) as hybrid-only vs hybrid+pure options. If my job is to provide modern cryptographic recommendations to a large organization, forcing hybrid-only now -- and only sometime later, okay, sure you can use pure now -- will consume literal years of my life, and countless engineering hours and dollars. --Daniel On Mon, Apr 6, 2026 at 9:26 PM Daniel Apon <[email protected]> wrote: > 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]
