I too strongly oppose publication (for the same reasons as others have already articulated).
I did not respond sooner as the flood of those supporting publication almost convinced me that it would be futile to oppose, but others are speaking out have enheartened me. Y(J)S -----Original Message----- From: Nadim Kobeissi <[email protected]> Sent: Sunday, June 28, 2026 2:31 PM To: Joseph Salowey <[email protected]> Cc: [email protected]; [email protected]; [email protected] Subject: [EXTERNAL] [TLS] Re: WG Last Call: draft-ietf-tls-mlkem-08 (Ends 2026-07-08) External Email: Be cautious do not click links or open attachments unless you recognize the sender and know the content is safe I oppose the publication of this document. Pure ML-KEM key exchange is a strict weakening of TLS 1.3 that brings absolutely no benefit over hybrid key exchange, something which has been standardized and deployed for years now to great success. This document only legitimizes a mode of operation for TLS the security of which is strictly less resistant than what we already have with hybrids, and which does not improve upon hybrid key exchange in any way, as shown and proven through various security analyses, some of which are cited in the draft itself. Nadim Kobeissi Symbolic Software • https://symbolic.software > On 24 Jun 2026, at 5:01 PM, Joseph Salowey via Datatracker <[email protected]> > 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/ > [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] This message is intended only for the designated recipient(s). It may contain confidential or proprietary information. If you are not the designated recipient, you may not review, copy or distribute this message. If you have mistakenly received this message, please notify the sender by a reply e-mail and delete this message. Thank you. _______________________________________________ TLS mailing list -- [email protected] To unsubscribe send an email to [email protected]
