IETF Logo Mail Archive

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

Bertrand Jacquin <bertrand@jacquin.bzh> Tue, 30 June 2026 20:57 UTC

Return-Path: <bertrand@jacquin.bzh>
X-Original-To: tls@mail2.ietf.org
Delivered-To: tls@mail2.ietf.org
Received: from localhost (localhost [127.0.0.1]) by mail2.ietf.org (Postfix) with ESMTP id 521E610B1F41A for <tls@mail2.ietf.org>; Tue, 30 Jun 2026 13:57:46 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1782853066; bh=03s3uOlKsMaV0LUWjw1+ej+LP8odlYIq7LCaX1Ln6XM=; h=Date:From:To:Cc:Subject:References:In-Reply-To; b=aM0dm8cuymF7Dn827yIxLSWEQ+R6ciVpsc8nQC/WxnKEKOUK6QiRoFZ5JrXl3btyx c/U/iArNUiM85l+6j2RDUcej04vgRp1bI83GU+DvKstAxt4eYslnDGlB/9U1ATKqa+ ltyQmgyyYvk7vlAKiYTjixxIE8T1oSd+m4F44Bbg=
X-Virus-Scanned: amavisd-new at ietf.org
X-Spam-Flag: NO
X-Spam-Score: -2.101
X-Spam-Level:
X-Spam-Status: No, score=-2.101 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: mail2.ietf.org (amavisd-new); dkim=pass (2048-bit key) header.d=jacquin.bzh
Received: from mail2.ietf.org ([166.84.6.31]) by localhost (mail2.ietf.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AEfAno8W4lWJ for <tls@mail2.ietf.org>; Tue, 30 Jun 2026 13:57:45 -0700 (PDT)
Received: from mx.eu-west-1.pants-on.net (mx.eu-west-1.pants-on.net [IPv6:2a05:d018:e2::25]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-256) server-digest SHA256) (No client certificate requested) by mail2.ietf.org (Postfix) with ESMTPS id 611D310B1F311 for <tls@ietf.org>; Tue, 30 Jun 2026 13:57:18 -0700 (PDT)
ARC-Seal: i=1; cv=none; a=rsa-sha256; d=mx.eu-west-1.pants-on.net; s=20240827.rsa; t=1782853038; b=N9yMggHBa/2u8z6myOpfZhFHMvQePt/83TbBDFnL+MPcyRr3tGh04m3oGP575I95qr0Gkg4sOc T/M3izfPA2p217PaSqYgDms0CRNnxFHkJxSXNfqOjpj0U5hElgFctXPYo9j97Mqid9tO0VIe6M MdlLTaAnFQYaK3av4ONe3BTX1DW+UV7hquAxK1cbK21w5tWa6QN9yGmA89C1GZRGyWjwKKu9GG UgHWPEO432eLPIRA18AZa5QP3RcLTpwwJvwGj36AcoAmY5mzY/XEsqauqMXuw3C8VH1sdpBAnp rYXNbCPguFp+sdDD7nhDf7Dk1ub363SdNmF/DRG0FkgsPw==;
ARC-Authentication-Results: i=1; mx.eu-west-1.pants-on.net; smtp.remote-ip=2001:470:1b3f:100:317a:3af8:6d4:8467; iprev=fail smtp.remote-ip=2001:470:1b3f:100:317a:3af8:6d4:8467; auth=pass (LOGIN) smtp.auth=bertrand@jacquin.bzh
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed; d=mx.eu-west-1.pants-on.net; s=20240827.rsa; t=1782853038; x=1785531438; bh=03s3uOlKsMaV0LUWjw1+ej+LP8odlYIq7LCaX1Ln6XM=; h=In-Reply-To:Content-Type:MIME-Version:References:Message-ID:Subject:Cc:To: From:Date:DKIM-Signature; b=NeEDjo0thv26nDS/uB42rDr+rUSfyEzMUNM/tAM7tyTTLE0do5nmSAMWlzVF3Jyw2+FGuUul7a YEWvrbUFsIy4sLoDQ0JH/LFDryVUqY+tOZRjbEBBlAGL20AndBKWXfzhf8HMQeXs6vSGtAxFY8 P6iQ5wbevDhOgm4/LUQMl1gcNBXqIVIqp+o6NOhS6NVr1+28n8P56n/v2AA1y4ez8lZzKNkw2A jGDdpUYoJSYLeeFyvWGL7kqBtlv3qr+0653jrxsGOWl/JnwaKOLqJqn7UI3ovhOL+69/p/Q7R1 G54/KKqq/2p4lORQnOvZz9GDGmKSE7K3NXNdOKvF6ZD1ow==;
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=jacquin.bzh ; s=20240222.rsa; h=BIMI-Selector:In-Reply-To:Content-Type:MIME-Version: References:Message-ID:Subject:Cc:To:From:Date:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive: Author; bh=awQt4YphwZNN8EbD5AVbIhkwSi+GaYYvqmrzzFaVN48=; i=@jacquin.bzh; t=1782853038; x=1785531438; b=mG9hioLTTuzYSplD9bKy73quHbnJeuFn9wjhpKl5U6a4UyP 3uZ5UKL9t2O+If3FJF2phfPt5XwKHU0PKelACq7IBNmNT7Rpso30oT0qLH563LrHygwoBYFfbTR5X BXYfE+sqYk2bzko6wAAyFFmE3CStWvVQpDm/wteRPWlPEpjCgS4hnzO41B3R52fVyB/I1Koxuf5Ax FrEKKKK50FEabRNEREPpTCu2RyPQ5SJpl/q1UxcKRMccK04WMxMeAvLiY6eKgZxOc2C0iczZLrRpc nNyVR0Gk8qm3vj8q9XJb9q8fElDbquePN29+1o+lUR0fM6gMVScxRi/NMm8+VOCQ==;
Authentication-Results: mx.eu-west-1.pants-on.net; iprev=fail smtp.remote-ip=2001:470:1b3f:100:317a:3af8:6d4:8467; auth=pass (LOGIN) smtp.auth=bertrand@jacquin.bzh
Received: from [2001:470:1b3f:100:317a:3af8:6d4:8467] (port=2656 helo=lady-voodoo.lan) by mx.eu-west-1.pants-on.net with esmtpsa (TLS1.3:TLS_AES_256_GCM_SHA384:256) id 1wefW8-00000000Z4F-0MY8 ; Tue, 30 Jun 2026 20:57:16 +0000
Date: Tue, 30 Jun 2026 21:57:00 +0100
From: Bertrand Jacquin <bertrand@jacquin.bzh>
To: Joseph Salowey <joe@salowey.net>, tls@ietf.org
Message-ID: <akQtnH-z417KPh12@lady-voodoo.lan>
References: <178231320760.1520243.5914961961176039994@dt-datatracker-f9b87776f-8pmmg>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg="pgp-sha256"; protocol="application/pgp-signature"; boundary="o3Lmj6QE2MFZhD93"
Content-Disposition: inline
In-Reply-To: <178231320760.1520243.5914961961176039994@dt-datatracker-f9b87776f-8pmmg>
Jabber-ID: bertrand@jacquin.bzh
X-GPG-Key: 0xA3B5C016618D9AAA
X-GPG-Fingerprint: D71B FE62 F66F 3C8B 1A25 A461 A3B5 C016 618D 9AAA
X-GPG-URL: https://keys.openpgp.org/vks/v1/by-fingerprint/D71BFE62F66F3C8B1A25A461A3B5C016618D9AAA
User-Agent: All mail clients suck. This one just sucks less.
BIMI-Selector: v=BIMI1; s=default;
Message-ID-Hash: D5LWIJZ3DTX5Y2KZ6PO2UJXVTX6P6BHT
X-Message-ID-Hash: D5LWIJZ3DTX5Y2KZ6PO2UJXVTX6P6BHT
X-MailFrom: bertrand@jacquin.bzh
X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-tls.ietf.org-0; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header
CC: draft-ietf-tls-mlkem@ietf.org, tls-chairs@ietf.org
X-Mailman-Version: 3.3.9rc6
Precedence: list
Subject: [TLS] Re: WG Last Call: draft-ietf-tls-mlkem-08 (Ends 2026-07-08)
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <tls.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/sbXARP74r1ZwIMk02t2Z2jaD1mw>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tls>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Owner: <mailto:tls-owner@ietf.org>
List-Post: <mailto:tls@ietf.org>
List-Subscribe: <mailto:tls-join@ietf.org>
List-Unsubscribe: <mailto:tls-leave@ietf.org>

Joseph, WG,

I have read draft-ietf-tls-mlkem-08. For the record: I do not
support publication of a standards-track document specifying
standalone ML-KEM key establishment for TLS 1.3.

Standalone removes the only classical hedge, and that is the wrong
default for TLS. Standalone ML-KEM is secure only if ML-KEM holds,
forever, against both classical and quantum cryptanalysis and against
implementation flaws in the field. The entire reason to deploy PQC in
TLS now, ahead of a cryptographically relevant quantum computer, is
harvest-now-decrypt- later. That threat model justifies adding a PQ KEM;
it never justifies removing the classical one. A hybrid such as
X25519MLKEM768 is secure if either component holds.

The proposal s a large bet on a young primitive. FIPS 203 was finalized
in 2024; lattice KEM cryptanalysis is far less mature than the decades
behind X25519 and the NIST P-curves. We have recent reminders that
"post-quantum" does not mean "safe": the 2022 classical break of SIKE
(Castryck-Decru) destroyed a scheme that had survived years of NIST
scrutiny, and the KyberSlash timing side channels (2023-2024) showed
that even reference ML-KEM code shipped exploitable secret- dependent
behaviour. None of this says ML-KEM is broken. It says betting the
confidentiality of the Internet's most important security protocol on a
single new primitive, with no fallback, is imprudent when the fallback
costs almost nothing.

And it does cost almost nothing. The classical half of the hybrid is 32
bytes and one X25519 scalar multiplication, lost in the noise next to
ML-KEM-768's ~1.1 KB public key and ciphertext. There is no performance
case for dropping it. The tradeoff is trivial cost against catastrophic,
retroactive downside. For TLS, that asymmetry alone settles it.

If the WG's clear, registered preference is hybrid, and the draft's own
Security Considerations now point at the registry to say so, then we are
about to publish a standards-track specification whose own text tells
you to prefer something else. That is self-undermining. The honest
outcome of a "hybrid preferred" consensus is to not ship a
standards-track standalone spec at all.

Key-share reuse changed to MUST NOT in rfc8446bis. Welcome, but
orthogonal. It resolves static-key reuse, forward secrecy and a privacy
concern. It does nothing about the absence of a classical hedge, which
is the actual objection. Citing it here is a non sequitur.

Once code points are standardized and implemented, they get enabled.
The recommendation column is advisory and is routinely overridden by
compliance mandates and procurement checklists. A WG standards-track RFC
confers exactly the legitimacy and momentum that drive deployment. "We
standardized it but marked it not recommended" is not protection; it is
a downgrade and foot-gun surface that we are choosing to create.

Cheers,
Bertrand

On Wednesday, June 24 2026 at 08:00:07 -0700, Joseph Salowey via Datatracker 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

-- 
Bertrand

v2.46.0 | Report a Bug | By Email | System Status