Hi Nadim, Thanks for this, I do think it would be a huge help for many posters to read and consider your points. I would like to add one further reason to support this draft: several very widely deployed libraries and applications are already implementing pure ML-KEM (I believe several have been cited previously in the discussion of this draft, by both sides), and I suspect more will over time. This draft specifies how to use it, security considerations, and also (most relevant to those in opposition of pure ML-KEM) that it is *not recommended*.
I do not personally oppose standalone ML-KEM. However, if I did, I would also support this draft, because the alternative appears to be many different parties supporting their own non-standardised take on pure ML-KEM [0], independent of the ability for the TLS WG to update security guidance or other recommendations. Presumably the external factors driving pure ML-KEM deployment do not depend on the TLS WG, given they already exist without the adoption of this draft. Presumably, then, if the TLS WG is unwilling to provide security guidance or recommendations, they will continue without the ability for the TLS WG to do so. If one believes the TLS WG should recommend against the use of pure ML-KEM then this draft includes that in Section 6. It’s important to separate opposition to the rollout of non-hybrid PQC from opposition to this draft. Best, Kevin [0] For whatever reason they have, but this is outside of the purview of the TLS WG so I don’t think it’s relevant to debate here. > On 1 Jul 2026, at 10:41, Nadim Kobeissi <[email protected]> wrote: > > 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 >> <[email protected]> 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 <[email protected]> >> Sent: 24 June 2026 16:00 >> To: [email protected]; [email protected]; [email protected] >> 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 -- [email protected] >> To unsubscribe send an email to [email protected] >
_______________________________________________ TLS mailing list -- [email protected] To unsubscribe send an email to [email protected]
