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

[Nadim Kobeissi <[e-mail]>]

Richard,

Reducing everyone who disagrees with you on technical merit to the status of a “troll” that’s “holding the IETF hostage” is absolutely unbecoming of you.

Saying that every single argument against this draft is “FUD” is simply wrong.

For instance, my argument from the start has been simple: since hybrids exist already, are specified, deployed and proven already, and since they constitute a successful post-quantum migration, it would be unjustified to abandon them for something that removes a layer of security assurance for absolutely no benefit in exchange.

Others have made more nuanced argument than how you represent them in your tirade and it’s a shame to see you reducing your peers like this.

If you’re wondering who’s trying to ram through their point of view by kicking and screaming here, please consider re-reading your email, Deb’s recent plea for civil behavior on-list, and adjusting accordingly.

Nadim Kobeissi

Symbolic Software • https://symbolic.software

On 7 Jul 2026, at 11:44 PM, Richard Barnes <[e-mail]> wrote:



Hi TLS folks,

Just publish this draft already.  The arguments have been hashed over a thousand times and they are all FUD.  They present no reason to prevent consenting systems from interoperating on this algorithm.

We need defense in depth! -- Why is this the one time in history that this is the case?  We didn’t do RSA-ECC hybrids during that transition.

What if governments try to coerce people into using it? -- An RFC isn’t going to make any difference, there are already public specs.

What if ML-KEM implementations have bugs? -- What if ECDH implementations have bugs?  Look at the age of Linux vulns coming out these days, age is no guarantee of quality.

This whole thing is honestly childish, like people can’t imagine that someone might make a different choice than they would.  The point of having negotiation in TLS is that different instances can make different decisions.  Reasonable people can disagree on whether bare ML-KEM is OK, and that’s all right.

Just publish it already.  Don’t let the IETF be held hostage by trolls.

—RLB

On Wed, Jun 24, 2026 at 5:00 AM Joseph Salowey via Datatracker <[e-mail]> wrote:

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/" rel="noreferrer nofollow" target="_blank">https://datatracker.ietf.org/doc/draft-ietf-tls-mlkem/
[2] https://datatracker.ietf.org/liaison/2198/" rel="noreferrer nofollow" target="_blank">https://datatracker.ietf.org/liaison/2198/
[3] https://datatracker.ietf.org/liaison/2151/" rel="noreferrer nofollow" target="_blank">https://datatracker.ietf.org/liaison/2151/
[4] https://datatracker.ietf.org/liaison/2148/" rel="noreferrer nofollow" target="_blank">https://datatracker.ietf.org/liaison/2148/
[5] https://datatracker.ietf.org/ipr/search/?submit=draft&id=draft-ietf-tls-mlkem" rel="noreferrer nofollow" target="_blank">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]

_______________________________________________
TLS mailing list -- [e-mail]
To unsubscribe send an email to [e-mail]