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 <dapon.crypto@gmail.com> 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 <
> muhammad_usama.sardar@tu-dresden.de> 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
>>
>