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 08:33 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 9D54ABA4FA75 for <tls@mail2.ietf.org>; Fri, 20 Feb 2026 00:33:00 -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="Oy9zTJUC"; dkim=pass (2048-bit key) header.d=messagingengine.com header.b="iczCCxea"
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 9KGz7l819H3r for <tls@mail2.ietf.org>; Fri, 20 Feb 2026 00:32:59 -0800 (PST)
Received: from fout-b4-smtp.messagingengine.com (fout-b4-smtp.messagingengine.com [202.12.124.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 E2761BA4FA6C for <tls@ietf.org>; Fri, 20 Feb 2026 00:32:59 -0800 (PST)
Received: from phl-compute-03.internal (phl-compute-03.internal [10.202.2.43]) by mailfout.stl.internal (Postfix) with ESMTP id DE0FA1D00198 for <tls@ietf.org>; Fri, 20 Feb 2026 03:32:52 -0500 (EST)
Received: from phl-imap-12 ([10.202.2.86]) by phl-compute-03.internal (MEProxy); Fri, 20 Feb 2026 03:32:52 -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=1771576372; x=1771662772; bh=CSQq7Wq72dYiFISH3FyfI yUR3TNEppHz7RQ5QzFBsZk=; b=Oy9zTJUCcZxaAjoIFzJ9RLtcl2YMhKEDKaxNq 5GAYSMkCPPQebjG7uc7KqBeLLfGuuEk1yWSJIWa3n7hDccqMVsT6BxcdZjhZhiEk KSgzqmuRLCEpqqoRGxJ2t/m1alvxb0AiddfPDvC10ZljGiE7eRrk9700sej2D+Cg KzRHtXlMFGnjmrWT6K4rJdl9HNXcx5eDQVgcmouRJ5VlQlp5Lo10SK6PSJ09tSu8 uVV4K1fexWdOhvovj7vgSTxmM9HUb9MR88B92WqO3WKPwqHhC1aDUnl3g9vG0mmc wE9mCkWNzYg23W6kr9CV9ieltYH5Kmp6WnBfW7GJTGvyBenBw==
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=1771576372; x=1771662772; bh=C SQq7Wq72dYiFISH3FyfIyUR3TNEppHz7RQ5QzFBsZk=; b=iczCCxea7LYHWDbIu LRXkZXTR5PqSkrd3/5tCfuy4rinfZU9oAi8dySrtzwiCLp82QpMY2ph/EkN1H/6Q U9iibSnn+UZp6EgGVr8dqspPtmRsQtEYsIH94Dn0CbrRAm4seU0ZeJASyr+UnMv9 FItTS3AknlV1SMw88My2OSDuGVhwL5a6AGqOvTkaILoQ7iWeuPQy0tx9baRYpP0K OEFNEMsIvuuYy++U6odf/IEuyG97al2W+HPlhQQzfL0MiSV/v/K5KjdYhnDyYbAq oDWMPF+l54duO13Vxrv947q5W8s9Uy1LwCwZYnjDB7/RQbUnvGoZNWcI9Uo2GaEN IKGHQ==
X-ME-Sender: <xms:NByYacP1oPXgzmDDGh3Vu9jM-jxAAesH9rCw8Q9_4pL7Jy4aAJlhTw> <xme:NByYadypqLddFJ7t9aBR6aj3ST6ndg9pzfG_VIwNSMKBBwmsMyYdtQhyG39MJs6mt 9QSUVAV6lnpvrwwgy8E7DxfdovNDXYkhQqD65H6jTV-XGkBdiBQ6CA>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeefgedrtddtgddvvdejleeiucetufdoteggodetrf dotffvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfurfetoffkrfgpnffqhgenuceu rghilhhouhhtmecufedttdenucenucfjughrpefoggffhffvkfgjfhfutgfgsehtqhertd ertdejnecuhfhrohhmpedfpfgrughimhcumfhosggvihhsshhifdcuoehnrgguihhmsehs hihmsgholhhitgdrshhofhhtfigrrhgvqeenucggtffrrghtthgvrhhnpedvhefghfetff duhfetveegieehjefhleeiffejteefjeejudeihfehtdeivdeiteenucffohhmrghinhep hhgrlhdrshgtihgvnhgtvgdpihgrtghrrdhorhhgpdhstghothhtrggrrhhonhhsohhnrd gslhhoghdpshihmhgsohhlihgtrdhsohhfthifrghrvgenucevlhhushhtvghrufhiiigv pedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpehnrgguihhmsehshihmsgholhhitgdrsh hofhhtfigrrhgvpdhnsggprhgtphhtthhopedupdhmohguvgepshhmthhpohhuthdprhgt phhtthhopehtlhhssehivghtfhdrohhrgh
X-ME-Proxy: <xmx:NByYaTyW8DD54YlqPUw7UO0KP650CJY_ELH8nmIf_zxEsfH4AUqMeg> <xmx:NByYaSP0WSu51RoTjlO9r57UT_4vOpqnWboksjeq9dSPrLhvvW95NA> <xmx:NByYaS_QCi1g0RWutbpzjIWR2Jd-6Zh1tMQeo6HFeN63pLl8S1y2Ww> <xmx:NByYaSpfbvoXouTIaxhvrFZyRr5EdTxExco7fq3fNCjxu_IBXqMshw> <xmx:NByYacLt673LFmz6yyo9tsimgZZauNY0CfZQA9lCI2grLmKeCRv4aGEk>
Feedback-ID: i6d3949ed:Fastmail
Received: by mailuser.phl.internal (Postfix, from userid 501) id 627DE1060065; Fri, 20 Feb 2026 03:32:52 -0500 (EST)
X-Mailer: MessagingEngine.com Webmail Interface
MIME-Version: 1.0
X-ThreadId: AdEwv1-X4yuN
Date: Fri, 20 Feb 2026 09:32:32 +0100
From: Nadim Kobeissi <nadim@symbolic.software>
To: tls@ietf.org
Message-Id: <93af0689-4bd3-4f6b-afaf-41869d27fa4d@app.fastmail.com>
In-Reply-To: <EB48AB24-A1A2-47C8-9C2C-47C93B9320E7@thomwiggers.nl>
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>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Message-ID-Hash: KESJT6WD555CALTUUUJMA3YX74OBR2WL
X-Message-ID-Hash: KESJT6WD555CALTUUUJMA3YX74OBR2WL
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/2iq2LrOywiexa3HiOSFv1LKrolc>
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 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

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