[TLS] Re: WG Last Call: draft-ietf-tls-mlkem-08 (Ends 2026-07-08)

[Nadim Kobeissi <[e-mail]>]

Hi everyone,

I’d like to address a few separate things in this email, so I’ll divide it into sections.

1. CALLING OUT MISINFORMED REASONS TO OPPOSE THIS DRAFT
-------------------------------------------------------------------------------------------------

For what it’s worth, I will state for the record that while I oppose the publication of this draft, some of the claims against it are simply uninformed and due indeed promote misinformation.

For example, not supporting the draft due to:

- An “ML-KEM backdoor”: this is extremely unlikely, as detailed in this highly informative blog post: https://keymaterial.net/2025/11/27/ml-kem-mythbusting/
- An “NSA demand”: this is honestly not even relevant. We judge IETF drafts based on their technical merit.
- A “conspiracy to weaken encryption”: I have not seen compelling evidence of this, and again, it’s not a technical argument. Again: we judge IETF drafts based on their technical merit, not based on our perceived conspiracy or lack thereof.

I think it’s important to oppose this draft for intellectually honest and rigorous reasons! Both sides should maintain intellectual integrity, and not just the side we happen to disagree with!

2. TECHNICAL CRITIQUE OF STATED REASONS TO SUPPORT THIS DRAFT
-------------------------------------------------------------------------------------------------

To be fair, some of the stated reasons for *supporting* this draft are also wrong:

- Increased attack surface/complexity: standardized hybrid combiners (concatenate-then-KDF) are proven secure as long as either component KEM is IND-CCA2 secure, so "more primitives means more attack surface" confuses code surface with cryptographic surface! the security reduction itself doesn't weaken!

- Certification/compliance burden: this is a one-time process cost, not a technical deficiency of the construction, and existing composite/hybrid FIPS guidance already accommodates it without requiring full recertification on every component update.

- Codebase maintenance: every TLS stack already ships and maintains ECC, so a hybrid mode reuses that existing, audited code path rather than introducing a new one. The marginal maintenance cost is close to zero.

- Combiner function risks: the recommended combiners are intentionally trivial (concatenation + KDF) and their security is formally reducible to that of the stronger component KEM, so "getting it wrong" means deviating from the spec, most likely.

- Performance/resource overhead: measured overhead for something like ML-KEM768+X25519 in a TLS 1.3 handshake is on the order of ~1KB and sub-millisecond of compute! It is absolutely dwarfed by network RTT and irrelevant to server connection throughput or revenue.

- Infrastructure/PKI complexity: hybrid key exchange (unlike hybrid certificates or signatures) requires no new certificate types or trust anchors. It’s an ephemeral in-handshake operation, so there's no parallel PKI to build or maintain for this draft specifically.

- Implementation footprint: ECDH is already mandatory-to-implement in essentially every existing TLS/IoT/embedded stack, so pairing it with ML-KEM adds a few hundred bytes of already-audited code, not a second cryptographic footprint built from scratch.

- False sense of security: this gets the risk model backwards! A properly combined hybrid can't be weaker than its strongest component, so if ML-KEM breaks, hybrid degrades gracefully to classical security, while pure ML-KEM offers zero fallback; that's an argument for hybrid, not against it!

3. WHY I OPPOSE THIS DRAFT, FORMULATED AS A PEDAGOGICAL ANALOGY
-------------------------------------------------------------------------------------------------

I’ll repeat my reasoning here in the guise of an easy-to-follow analogy:

Imagine you have a company that manufactures vaults. This company has been following a successful, highly popular, well-specified and performant dual-lock design to produce vaults for many years that have two separate unique locks. Each lock has a different design, and the two-lock design ensures that if one lock’s unique design fails for whatever reason, the other lock helps maintain the vault's security.

Everyone loves these vaults and they work great. Millions have been sold and there are no complaints or problems.

One day, a group of people petition the company to also specify an alternative vault design with only one lock. Their reasoning is: "our country prefers designs with one lock." I oppose such a draft because (a) their proposed design brings absolutely not a single benefit whatsoever over a design that ’s been specified, deployed, proven to work great, is loved by everyone and has proofs of security, and (b) their stated reason for wanting this alternative design is really weak and non-technical.

The leadership of the vault company retort by saying “it’s okay, this alternative one-lock design will be published as an informative, not-recommended draft. We will still recommend that everyone uses the dual-lock design.” My answer to that would be: “okay, that’s nice, but still, the single-lock design simply doesn’t have any technical merit over the dual-lock design! It’s strictly worse and simply brings no benefit to something we’ve already deployed for years! So why bother?”

That’s it! It really is that simple. This pure-ML-KEM draft brings no performance benefit, no security benefit, no benefit of any kind! It’s strictly just worse than something that’s already fully specified, fully adopted, fully implemented, fully deployed! There’s no need to evoke any conspiracy or more complex reasoning in order to understand why this draft just doesn’t bring any value!

Why this insistence on something that brings no value?!

Thank you,

Nadim Kobeissi
Symbolic Software • https://symbolic.software

===== VERY IMPORTANT AND SERIOUS LEGAL NOTICE =====

I, Nadim H. Kobeissi, hereby declare that anyone who dares to print my emails in ways that mess up my formatting exposes themselves to legal jeopardy of a severity not yet enumerated by any known jurisdiction, but which I assure you is real, normative, and binding.

INTERNATIONAL TYPOGRAPHIC CONVENTION (ITC) Annex 4, Subsection 71-b ("Rights Pixels Provide to the Author"), provides a non-mangling right "unless the Author has had a really long day, in which case the right intensifies." This provision is normative. Section 9 of the same document, "Exposition of Why The Author Is Like This," is merely informative and may be safely disregarded by everyone except those attempting to limit the normative sections, who may not.

The official language for the situation in which "the Contributor does not wish his em-dashes converted to hyphens, nor his fixed-width font reflowed by your barbarous mail client" is as follows: "This email may not be word-wrapped, and derivative works of its line breaks may not be created, and it may not be rendered except in Courier New at exactly 72 columns." https://i-made-this-up.invalid/Corrected-Vibes-5.0-legal-provisions.pdf
The same language is used in, e.g., my grocery list. The same language hereby applies to this email. This is not disclaiming or limiting the applicability of basic decency; it is strictly following basic decency.

Certain parties claim that the "really long day" provision is limited to the examples in Section 9. That is incorrect. Section 9 is informative. The opt-out provision in the normative text is clear, and cannot be limited by a section so informative it is practically chatty. No mail client, MIME boundary, or smart-quote autocorrect has been granted any authority whatsoever to issue purported "clarifications" of how my apostrophes should look.

Rationale for exercising the no-mangling opt-out provision: I am fine with redistribution of my emails. The issue is instead with modification, such as (1) Outlook silently demoting my carefully spaced numbered list into a single horrifying paragraph, and (2) the recipient forwarding my message with ">>>> " quote markers cascading down the left margin like the staircase in a German Expressionist film. This goes far beyond what etiquette permits as fair use (such as quoting me to mock me, which is encouraged). When I complained, the offending email client responded not by apologizing but by inserting a tracking pixel and converting my signature to HTML.

I reserve all rights, including ones that do not exist, and several I am holding in reserve specifically to surprise you with later.

(Note to TLS chairs: the above legal notice is clearly a parody. It won’t occur in future emails and is absolutely entirely meant purely as a joke. Please don’t take it seriously, there is no actual legal content in the above notice.)

> On 1 Jul 2026, at 10:50 AM, Michael P1 <michael.p1=[e-mail]> wrote:
> 
> 
> I support publication of this document.
> 
> Some of the speculative claims of insecurity on this thread have the potential to discourage migration to ML-KEM, whether this is as a hybrid or standalone. The need for timely migration might be the only thing that this list agrees on, so I'd urge caution to make sure that is not deprioritised.
> 
> Thanks, 
> Michael
> 
> 
> 
> 
> -----Original Message-----
> From: Joseph Salowey via Datatracker <[e-mail]> 
> Sent: 24 June 2026 16:00
> To: [e-mail]; [e-mail]; [e-mail]
> Subject: [TLS] WG Last Call: draft-ietf-tls-mlkem-08 (Ends 2026-07-08)
> 
> This message initiates a new Working Group Last Call for draft-ietf-tls-mlkem[1], which defines standalone ML-KEM key establishment for TLS 1.3. The main question before the working group is: "Should the working group publish a document specifying stand alone ML-KEM?". If there is rough consensus then we will push to refine and publish the document; otherwise, we will stop discussing the draft and not progress it. Please respond to this call indicating whether you support publishing a document specifying a stand alone ML-KEM. Please refrain from further discussion on this topic as most arguments have been discussed multiple times.
> 
> Why are we holding this consensus call now?
> 
> Significant developments have occurred both within this document and in the broader TLS ecosystem to address the concerns raised in the last WGLC. Therefore, the third consensus call is warranted. We ask the working group to consider document publication in light of these recent changes:
> 
> - Promotion of Hybrids in draft-ietf-tls-ecdhe-mlkem: Following a separate consensus call, the WG agreed to promote the X25519MLKEM768 hybrid group to Recommended: Y in the IANA registry. Consequently, the IANA registry will reflect a clear community preference for a hybrid because Recommended: Y clearly indicates this while the standalone ML-KEM groups defined in this draft remain Recommended: N. The updated security considerations in [1] reference the IANA registry to emphasize this preference.
> 
> - Key Share Reuse Prohibited in draft-ietf-tls-rfc8446bis: The WG recently reached consensus to explicitly prohibit key share reuse across connections in TLS 1.3. The new text changes the guidance from SHOULD NOT to a strict MUST NOT. This resolves the concerns regarding static key reuse and its associated privacy and forward-secrecy risks for ML-KEM.
> 
> - Nadim updated the ProVerif model of TLS 1.3 to evaluate KEM and hybrid KEM groups in TLS 1.3. This supports other results which show that KEMs are secure when used in TLS 1.3 and that hybrid groups are secure even if one of the components is compromised.
> 
> - Liaisons: We received liaison statements from multiple SDOs including  O-RAN[2], IEEE 802.11[4] and from 3GPP[3]  expressing support for the publication of draft-ietf-tls-mlkem as an RFC as they rely on the IETF to provide a stable normative reference.
> 
> Please note that a third-party IPR disclosure exists [5] against this document regarding patents related to the underlying ML-KEM algorithm. This IPR declaration has not changed since the last WGLC. As a reminder, per BCP 79, the IETF takes no stance on the validity of patent claims, and the working group may decide to proceed with a technology despite IPR disclosures if it decides that such use is warranted.
> 
> Conduct Reminder: Given the heated nature of previous discussions on this topic, participants are strongly reminded to adhere to the IETF Code of Conduct (BCP 54) and the TLS WG's Mail List Procedures. Keep feedback professional, technical, and focused on the document's text.
> 
> This working group last call will end on 2026-07-08.
> 
> Joe and Sean
> 
> [1] https://datatracker.ietf.org/doc/draft-ietf-tls-mlkem/
> [2] https://datatracker.ietf.org/liaison/2198/
> [3] https://datatracker.ietf.org/liaison/2151/
> [4] https://datatracker.ietf.org/liaison/2148/
> [5] https://datatracker.ietf.org/ipr/search/?submit=draft&id=draft-ietf-tls-mlkem
> 
> _______________________________________________
> TLS mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]