IETF Logo Mail Archive

[TLS] Re: WG Last Call: draft-ietf-tls-mlkem-05 (Ends 2026-02-27)

Nadim Kobeissi <nadim@symbolic.software> Fri, 20 February 2026 12:41 UTC

Return-Path: <nadim@symbolic.software>
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 1E2C7BA645D7 for <tls@mail2.ietf.org>; Fri, 20 Feb 2026 04:41:06 -0800 (PST)
X-Virus-Scanned: amavisd-new at ietf.org
X-Spam-Flag: NO
X-Spam-Score: -2.799
X-Spam-Level:
X-Spam-Status: No, score=-2.799 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, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_VALIDITY_CERTIFIED_BLOCKED=0.001, RCVD_IN_VALIDITY_RPBL_BLOCKED=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: mail2.ietf.org (amavisd-new); dkim=pass (2048-bit key) header.d=symbolic.software header.b="NtLtTNcf"; dkim=pass (2048-bit key) header.d=messagingengine.com header.b="f4uZwRHx"
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 XlEVwQfCSBt1 for <tls@mail2.ietf.org>; Fri, 20 Feb 2026 04:41:03 -0800 (PST)
Received: from fout-a4-smtp.messagingengine.com (fout-a4-smtp.messagingengine.com [103.168.172.147]) (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 DFC0ABA6454B for <tls@ietf.org>; Fri, 20 Feb 2026 04:41:03 -0800 (PST)
Received: from phl-compute-03.internal (phl-compute-03.internal [10.202.2.43]) by mailfout.phl.internal (Postfix) with ESMTP id 99A2BEC05D0 for <tls@ietf.org>; Fri, 20 Feb 2026 07:40:57 -0500 (EST)
Received: from phl-imap-12 ([10.202.2.86]) by phl-compute-03.internal (MEProxy); Fri, 20 Feb 2026 07:40:57 -0500
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= symbolic.software; h=cc:content-transfer-encoding:content-type :content-type:date:date:from:from:in-reply-to:in-reply-to :message-id:mime-version:references:reply-to:subject:subject:to :to; s=fm1; t=1771591257; x=1771677657; bh=en0bDUmFi59P7V7nolRof l4Y9GvD889SFKgPb/EZja8=; b=NtLtTNcfRRA7dbLIwC/BJXFWr9snqC7vfvd+J BNh9/i3prVc/BkgWh+OzOfuLZ75IhJjNJb+vzplkcV5GlrLlyKk3BVrxW//7T+HV Rd0B8kb/LgNEJGO5Om9Wqo6RWelPxyvu29zRXIhqC3w3boaavclIrS8dJ/QonC59 TV8Za0H+pEwCZAkBTEWqPHqX7AL9WBoDkEZGnB+eC8d1DQbwfJmNoJTEjPC5i5VW UiedIAAt0WMSlWtjK6CN26rKFQ0pyIu+qmOBt5AYdgT60BjcJUS/puQZZ3TXh6Tl vLRxIVjMRPb4pGO1V/Hog8JR1k7ETnhPydF9wdMQuglxnFtEQ==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :content-type:date:date:feedback-id:feedback-id:from:from :in-reply-to:in-reply-to:message-id:mime-version:references :reply-to:subject:subject:to:to:x-me-proxy:x-me-sender :x-me-sender:x-sasl-enc; s=fm3; t=1771591257; x=1771677657; bh=e n0bDUmFi59P7V7nolRofl4Y9GvD889SFKgPb/EZja8=; b=f4uZwRHxdn8QBEf7R l4NXgk42N17hp+Gp2Xf6Lh5VqKvrFI07ZgV6ouE+OkrCJ6ff8x7n0NrEmejTp6n7 e6DWvUZFjtHCKnR21zqx7O/8np/YJo57nIHKFpR7KSvzNGVFI2+DAzF9Qnw3j5vB jVvaU+p61cXduBwTZm29YPF7KWnYszfBMWCviB1uS9V6iI9plDkku/2eDShImzWk eD5Awc9wkr69QiKUfZw3Fa58LPEsZB53yGThMNvdSIR8mX4JkZdccc3PnNS/bcF7 SWQLVn8WmgVUD8+9Ox0ihTy9BNK+AAqWnmBBjTmZkbZ+7HQXPZRADTa+vrEz/xmo KMB0g==
X-ME-Sender: <xms:WVaYaS2ruVcfFwxDBmxpErxpyFcmhIS6VYbwqKWbFWgSwzdUowtHOg> <xme:WVaYaf4j49gzt3VInwH09bjNSU38STZ7ygEHZKksqPO-GV-mcVccHHj7QEVQfc0pZ VZAhjlHjrEZ0Rbq490f3gMeFTVaZKCl4wGdc05Lb4IQZZo3trrR8sI>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeefgedrtddtgddvvdekgeeiucetufdoteggodetrf dotffvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfurfetoffkrfgpnffqhgenuceu rghilhhouhhtmecufedttdenucenucfjughrpefoggffhffvkfgjfhfutgfgsehtqhertd ertdejnecuhfhrohhmpedfpfgrughimhcumfhosggvihhsshhifdcuoehnrgguihhmsehs hihmsgholhhitgdrshhofhhtfigrrhgvqeenucggtffrrghtthgvrhhnpedvhefghfetff duhfetveegieehjefhleeiffejteefjeejudeihfehtdeivdeiteenucffohhmrghinhep hhgrlhdrshgtihgvnhgtvgdpihgrtghrrdhorhhgpdhstghothhtrggrrhhonhhsohhnrd gslhhoghdpshihmhgsohhlihgtrdhsohhfthifrghrvgenucevlhhushhtvghrufhiiigv pedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpehnrgguihhmsehshihmsgholhhitgdrsh hofhhtfigrrhgvpdhnsggprhgtphhtthhopedupdhmohguvgepshhmthhpohhuthdprhgt phhtthhopehtlhhssehivghtfhdrohhrgh
X-ME-Proxy: <xmx:WVaYaebOHj3pi8VYu3fXdxqT2viKGGjQCAgAJ3U_-6pIt7UkSpOxvw> <xmx:WVaYaYXQqIr9lHmQwbpbinY1e-YCOqkL1T26BSfxJAouHE-QUuI7pg> <xmx:WVaYaemx9sE8QOZgOH_ZChCAUv2H_4k9d3qMCMav_kwcOXuKrRWOMQ> <xmx:WVaYaVyXIrNVL5k9h0AoxMZ31Z09S0Wi3i-OHs1JOpdUI6Pu3JhW8w> <xmx:WVaYaVxCKffluxXjInOo714H_qS6yXPLDGY5Pd8Car5ndTkFNShkJ9KW>
Feedback-ID: i6d3949ed:Fastmail
Received: by mailuser.phl.internal (Postfix, from userid 501) id 6A8A11060065; Fri, 20 Feb 2026 07:40:57 -0500 (EST)
X-Mailer: MessagingEngine.com Webmail Interface
MIME-Version: 1.0
X-ThreadId: AdEwv1-X4yuN
Date: Fri, 20 Feb 2026 13:40:34 +0100
From: Nadim Kobeissi <nadim@symbolic.software>
To: tls@ietf.org
Message-Id: <6b6a7346-5c7f-40b3-ac63-4d49bf05caa5@app.fastmail.com>
In-Reply-To: <93af0689-4bd3-4f6b-afaf-41869d27fa4d@app.fastmail.com>
References: <20260218194044.1135896.qmail@cr.yp.to> <7C9C99AA-42B0-4BC7-8F41-39F35754F1C4@vigilsec.com> <MN2PR17MB40310F0A2891942D76C43E60CD6BA@MN2PR17MB4031.namprd17.prod.outlook.com> <2caab265-00ba-4078-b6d0-3a178dabaa61@tu-dresden.de> <CAEEbLAbkV4YxN7cgggckpEp24MLtRZpzs6M4KemBatpzCCcs0A@mail.gmail.com> <MEAPR01MB3654415F735DE96CEE239C78EE68A@MEAPR01MB3654.ausprd01.prod.outlook.com> <aZfbhrFDBp7a0xHL@chardros.imrryr.org> <EB48AB24-A1A2-47C8-9C2C-47C93B9320E7@thomwiggers.nl> <93af0689-4bd3-4f6b-afaf-41869d27fa4d@app.fastmail.com>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Message-ID-Hash: 3S5ZAMDYEZVB4ZVLWN2P5HXE3VB2WVU4
X-Message-ID-Hash: 3S5ZAMDYEZVB4ZVLWN2P5HXE3VB2WVU4
X-MailFrom: nadim@symbolic.software
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
X-Mailman-Version: 3.3.9rc6
Precedence: list
Subject: [TLS] Re: WG Last Call: draft-ietf-tls-mlkem-05 (Ends 2026-02-27)
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/8LGECBbDbTI15kfnZKt6tSJxOQs>
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>

Hi again,

It looks like draft-ietf-tls-mlkem-07 has an expanded Motivation section, adding:

> Use cases include regulatory frameworks that require standalone post-quantum key establishment, targeting smaller key sizes or less computation, and simplicity.

This is not a compelling or legitimate reason. The IETF should be publishing specifications that improve security, privacy and performance around the world, in line with the global public interest, and not to please arbitrary regulatory frameworks of specific countries, especially when those come at the expense of the studied and proven compositional security guarantees of hybrid constructions.

I'm sure that different governments could have very different ideas regarding what constitutes a legitimate regulatory framework: In 2015, the government of Kazakhstan created a root certificate which could have enabled a man-in-the-middle attack on HTTPS traffic from Internet users in Kazakhstan. Kazakhstan tried to do this again in 2019, and once more in 2020.

If the Kazakh government were to propose a regulatory framework that would be in line with such a weakening of TLS's security guarantees, should be formulate an IETF draft to accommodate it?

If the answer is no, then why is a request from any other government that aims to allow for PQ-only key agreement constructions, which would reintroduce entire classes of attacks, or reduce key sizes, more legitimate?

When we publish specifications, we should be doing so because they are good ideas, because they improve the security and privacy of people worldwide, or because they propose performance improvements while maintaining these proven security guarantees. We should not be publishing specifications because a big impressive authority would like us to, in spite of serious potential negative effects on our studied and proven compositional security guarantees.

On Fri, Feb 20, 2026, at 9:32 AM, Nadim Kobeissi wrote:
> Hi everyone,
>
> I would like to register my objection to the publication of this draft.
>
> My background in formal verification of TLS 1.3 (e.g. 
> https://inria.hal.science/hal-01528752/file/RR-9040.pdf) makes me 
> particularly attentive to compositional security properties. Hybrid 
> constructions provide a clean guarantee: key establishment remains 
> secure under compromise of either component. This is a property worth 
> preserving, and the draft offers no justification for discarding it.
>
> I am in all honesty completely baffled by the highly unusual insistence 
> to adopt this draft. As I understand it:
>
> - Hybrid constructions protect us from classes of attacks that pure-PQ 
> constructions do not protect us against.
> - Hybrid constructions have a negligible overhead compared to pure-PQ 
> constructions.
>
> Despite my attempts at good faith engagement with the text of 
> draft-ietf-tls-mlkem-05, I struggle to determine any benefit that a 
> pure-PQ construction can possibly have when compared to a hybrid 
> construction aside from eliminating a negligible performance overhead. 
> And yet, adopting a pure-PQ key establishment option for TLS 1.3 
> renders it vulnerable to an entire class of attacks that hybrid 
> constructions were designed to eliminate.
>
> The world's Internet has been happily running TLS 1.3 with hybrid 
> constructions for years now, providing robust security guarantees 
> against SNDL attacks (thanks to ML-KEM) as well as higher assurance 
> against classical attacks in PQ constructions (thanks to ECC), since, 
> as we know, these are relatively much less mathematically well-studied 
> than their classical counterparts.
>
> One would think that applying such an important change to such a happy 
> and problem-free status quo would require exceptional motivation. And 
> yet, the Motivation section of draft-ietf-tls-mlkem-05 is completely 
> circular. Here it is, in its entirety:
>
>> FIPS 203 (ML-KEM) [FIPS203] is a FIPS standard for post-quantum
>> [RFC9794] key establishment via lattice-based key establishment
>> mechanism (KEM).  Having a purely post-quantum (not hybrid) key
>> establishment option for TLS 1.3 is necessary for migrating beyond
>> hybrids and for users that want or need post-quantum security without
>> hybrids.
>
> This motivation section contains zero bits of entropy. It's like saying 
> "this green banana store exists for people who prefer green bananas to 
> yellow ones." Okay? But why would anyone prefer that in the first 
> place? The motivation remains completely unexplained aside from it 
> being self-referential.
>
> In all honesty, this draft is just completely inexplicable, even 
> bizarre, to me. It would re-introduce an entire class of attacks to the 
> TLS key establishment protocol and I have absolutely no idea what the 
> tangible benefit is in that equation.
>
> Please do not adopt this draft.
>
> On Fri, Feb 20, 2026, at 8:58 AM, Thom Wiggers wrote:
>> Hi all,
>>
>> I support the publication of this draft.
>>
>> Cheers,
>>
>> Thom 
>>
>>> Op 20 feb 2026, om 04:56 heeft Viktor Dukhovni <ietf-dane@dukhovni.org> het volgende geschreven:
>>> 
>>> On Fri, Feb 20, 2026 at 01:18:52AM +0000, Peter Gutmann wrote:
>>> 
>>>> Unless it's PQC, in which case the minute it's in the spec, in fact long
>>>> before there's even a spec for it, everyone will be clamouring for it to
>>>> appear.  Not arguing against publication, just pointing out that when it comes
>>>> to post-magic crypto the only choices you have are "support it" or "support
>>>> it".
>>> 
>>> OpenSSL 3.5 and later do indeed provide an implementation, but FWIW, the
>>> non-hybrid ML-KEM groups are not enabled by default, both client and
>>> server have to choose to enable them explicitly in their configurations.
>>> 
>>> Only X25519MLKEM768 is enabled by default, and in 4.0 we'll shortly add
>>> a default fallback to the SecP256r1MLKEM768 hybrid (but without a
>>> predicted client keyshare, so used only after a server HRR, if the
>>> server for some reason supports the P-256, but not the X25519 hybrid).
>>> 
>>> Once a VIC-20, an abacus or a dog[1] can no longer beat demonstrated
>>> implementations of Shor's algorithm, perhaps the pure ML-KEM variants
>>> would also make sense to enable by default.
>>> 
>>> Before I take CRQCs as a credible looming issue, a milestone I'd want to
>>> see crossed would be an honest Shor's algorithm factorisation of a
>>> 32-bit RSA modulus[2], but perhaps I should first have asked for a
>>> 16-bit RSA moduls instead, as that too appears to be currently well out
>>> of reach.
>>> 
>>> -- 
>>>    Viktor.  🇺🇦 Слава Україні!
>>> 
>>> [1] https://eprint.iacr.org/2025/1237.pdf
>>> [2] https://scottaaronson.blog/?p=9564#comment-2025810
>>> 
>>> _______________________________________________
>>> TLS mailing list -- tls@ietf.org
>>> To unsubscribe send an email to tls-leave@ietf.org
>>
>> _______________________________________________
>> TLS mailing list -- tls@ietf.org
>> To unsubscribe send an email to tls-leave@ietf.org
>
> -- 
> Nadim Kobeissi
> Symbolic Software • https://symbolic.software

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

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