[ # include <Ekr's apology boilerplate for nitpicking [6] > ]
I really appreciate Daniel retracting his statement that "IEEE is asking TLS WG to 'please hurry up'".
I am in full agreement with Ekr on his responses [6] to Daniel's email below.
FWIW, in addition to that, I personally find Daniel's other arguments unconvincing and increasingly off-topic. If anything, such circular debates only increase my already strong support for draft-barnes-tls-this-could-have-been-an-email.
3GPP LS that Daniel is talking about is simply a draft. IIUC (John, please correct me if I am wrong) it doesn't yet have a consensus in 3GPP and is still to be discussed in the next meeting. Let's not speculate and discuss that when that has an agreement in 3GPP and received in the TLS WG. Please don't put undue pressure on the WG. Everyone is a volunteer here.
Contrary to the argument of Google's 2029 -- that's being used to create urgency -- Google is actually currently recommending hybrids (with "some caveats" which I am looking forward to). Google blog post [7] -- which is mentioned in Google's 2029 timeline post [8] -- actually states:
> While the currently proposed PQC algorithms have received a lot
of cryptanalysis over the last decade, they are still somewhat less
mature than classical cryptography, and our recommendation is to use
them in a hybrid fashion, which requires an attacker to break both
the classical and the post-quantum algorithm. There are some caveats
on this topic that we will explore in a future blog post.
IIUC Sophie -- one of the authors of both posts [7,8] -- is a strong
proponent of non-hybrid but that is not the current official position of
Google, as evidenced by the above statement from [7]. If that is not
correct, it would be helpful for Google to send IETF a LS explaining
precisely its official position. For example, does it actually mean
migrating fully to pure ML-KEM (or PQC in general) by 2029? Until then,
I would encourage the WG to continue its due diligence on the
substantial concerns raised by a couple dozen folks in the WGLC and
avoid inferring urgency without clear technical justification. In the
LS, Google should also explain why it needs a RFC and why the codepoints
are insufficient?
FWIW, I want to enlist my points to which I believe Daniel has provided no substantive response:
1. Explain genuine urgency for pure ML-KEM 2. Proof that pure ML-KEM is more secure than hybrid in TLS 3. Technical rationale for pure ML-KEM in TLS for IEEE 802.11bt project 4. Technical relevance of Google's 2029 to IEEE 802.11 LS 5. Why is this problematic for IEEE to publish this draft? That seems like a win-win for everyone while also saving everyone's time. 6. Evidence of "international consensus" on use of pure ML-KEM within the TLS protocolI would appreciate precise and concise technical responses to those points. Thank you!
Also, see inline: On 07.04.26 03:26, Daniel Apon wrote:
"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).
Seems increasingly off-topic. See note on Google in the beginning.
Thank you, but I don't see any relevance. For IEEE 802.11 LS -- the topic at hand in this thread -- [3] directly quotes the 2035 deadline. Let's not speculate and discuss it when IEEE 802.11 changes that.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.
While this specific slide in [5] states November 2025 (which seems like typo; maybe they copied slide from November and forgot to update month/year), reading just the file name tells me that it is March 2026 report, and hence updated based on the March 2026 meeting. I may be missing some IEEE specifics here, and Russ can correct me if I am wrong but that's what I understand.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.
As mentioned in the beginning of email for 3GPP.
So, I retract my statement that "IEEE is asking TLS WG to 'please hurry up'"
Thanks very much!
-- instead, it should be that 3GPP SA3 from ETSI finds relying on numbered internet-drafts insufficient in place of an RFC.
Ditto as above for 3GPP.
I don't find any compelling reason for "disagree with the conclusion". I continue to strongly support draft-barnes-tls-this-could-have-been-an-email to save WG energies for useful work.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 would become /if/ and /when/ there is (rough) /consensus/ in the TLS WG and more broadly in IETF to publish it. We are way far from that.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.
The point is that international consensus does not make ML-KEM bullet-proof.
If this is a false dichotomy, why should the IETF even discuss its standardization in TLS?However, I also believe that requiring me to further claim international consensus for "pure ML-KEM" is, genuinely, a false dichotomy.
My point was that algorithm security and protocol integration are two orthogonal issues. As an example, ML-KEM could be secure, and still integrated in insecure way in TLS. There is a large history of protocol attacks that existed even when the cryptorgraphic primitives (algorithms) were assumed to be perfect. I invite you to check out [1,9-11] -- as a few examples -- and explain to me why these attacks exist even with perfect crypto primitives (ECDHE).
In my own company's systems, I have situations where I'd prefer to use pure ML-KEM,It would be helpful for WG to contribute those "situations" to be added in the draft. That would actually help this draft move forward.
Thank you. This is actually helpful. Please propose text for motivation in the draft.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.
(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.)
I am not sure if this is any helpful.
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.
Fully agree with Ekr's response [6] on this.In addition, equating two dozen folks simply stating 'I support publication' is not the same as the two dozen folks highlighting significantly substantial concerns in full detail (such as [12]).
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.
Fully agree with Ekr's response [6] on this.Moreover, it's not at all clear to me why one would do a security regression in TLS from hybrids for apparently a very small one-time setup performance impact.
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?
Fully agree with Ekr's response [6] on this. 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
(Slide 6)
[6] https://mailarchive.ietf.org/arch/msg/tls/EmVFQEmhoXKsK5E3B6X5nIHPQPg/[7] https://bughunters.google.com/blog/googles-threat-model-for-post-quantum-cryptography
[8] https://blog.google/innovation-and-ai/technology/safety-security/cryptography-migration-timeline/
[9] https://www.researchgate.net/publication/398839141_Identity_Crisis_in_Confidential_Computing_Formal_Analysis_of_Attested_TLS
[10] https://github.com/ultravioletrs/cocos/security/advisories/GHSA-vfgg-mvxx-mgg7
[11] https://nvd.nist.gov/vuln/detail/CVE-2026-33697 [12] https://mailarchive.ietf.org/arch/msg/tls/jlsYHENwqMv-4XPRvunqKsAL36k/
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ TLS mailing list -- [email protected] To unsubscribe send an email to [email protected]
