[TLS] Re: New Liaison Statement, "Liaison communication to IETF regarding draft-ietf-tls-mlkem"

[Muhammad Usama Sardar <[e-mail]>]

[ # 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 protocol

I 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.
>
> 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.
>
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.

>
> 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).
>
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.
>
> 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.
>
> 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.)
>
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.
>
> 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])?
>
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.
>
>
> 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.
>
> However, I also believe that requiring me to further claim 
> international consensus for "pure ML-KEM" is, genuinely, a false 
> dichotomy.
>
If this is a false dichotomy, why should the IETF even discuss its 
standardization in TLS?

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.
>
> 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.
>
Thank you. This is actually helpful. Please propose text for motivation 
in the draft.
>
> (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/