I apologize in advance for the fact that this message is going to seem nitpicky, but I really do think it's important to be clear on precisely what the controversy is about and what it is not about.
On Mon, Apr 6, 2026 at 6:27 PM Daniel Apon <[email protected]> wrote: > > 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 is not correct. There is already a code point assignment for pure ML-KEM. The sole question is whether the IETF will publish an RFC specifying it or leave the code point registration pointing to the I-D, as it currently does, with the possibility that someone will publish some other archival document, RFC or not, that can be used as a reference. 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. > Again, not quite: it's rather about whether people who require there to be an IETF RFC will be able to do so (I don't know whether this is half of the body politic or not). 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. > Once again, not quite. This document is up for Informational, not for PS. So in any case it will be standardized later, if at all. 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? > No, I don't think this is right either, for the reasons indicated above. Nothing stops you using the existing code point right now. I do understand that there are people who want to have an RFC and for whom there not being one may be quite inconvenient (per the points David Benjamin, Russ, and others have raised), and those people will have to figure out how to have a permanent reference, but it's not in fact the case that any plausible action by the IETF will *require* them to use hybrid-mode TLS only, even in the sense that there is a RFC 2119 requirement to do so. At most it's that the IETF will not have published an RFC specifying it pure ML-KEM. -Ekr > > 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] >
_______________________________________________ TLS mailing list -- [email protected] To unsubscribe send an email to [email protected]
