IETF Logo Mail Archive

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

Jacob Appelbaum <jacob@appelbaum.net> Thu, 26 February 2026 23:59 UTC

Return-Path: <jacob@appelbaum.net>
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 8C1D0BF20AAD for <tls@mail2.ietf.org>; Thu, 26 Feb 2026 15:59:10 -0800 (PST)
X-Virus-Scanned: amavisd-new at ietf.org
X-Spam-Flag: NO
X-Spam-Score: -2.797
X-Spam-Level:
X-Spam-Status: No, score=-2.797 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_MSPIKE_H5=0.001, RCVD_IN_MSPIKE_WL=0.001, RCVD_IN_VALIDITY_CERTIFIED_BLOCKED=0.001, RCVD_IN_VALIDITY_RPBL_BLOCKED=0.001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: mail2.ietf.org (amavisd-new); dkim=pass (2048-bit key) header.d=appelbaum.net
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 dVx55GeO8Wv7 for <tls@mail2.ietf.org>; Thu, 26 Feb 2026 15:59:09 -0800 (PST)
Received: from relay7-d.mail.gandi.net (relay7-d.mail.gandi.net [217.70.183.200]) (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 D98EDBF20AA1 for <tls@ietf.org>; Thu, 26 Feb 2026 15:59:08 -0800 (PST)
Received: by mail.gandi.net (Postfix) with ESMTPSA id 9B8E641B57; Thu, 26 Feb 2026 23:59:00 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=appelbaum.net; s=gm1; t=1772150341; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:autocrypt:autocrypt; bh=PTP2kSD6r9rYzvxEHC9++QY1ycMhMGf0GnXk64CYB18=; b=mEF1zFRmo7GN8PTrrg0Nj7DGG0WQW0TKu3TfSirV+Wiuf5vw9L+FXfLdBTeZHnCRZJN1KN E+qFE7IbS6zKWPHSgiFt80GOnV32zsXuhIS8FQCnyG+fSV6qA0ccvprE/WPNW6n6Jpc7U7 CsmwdILlwz496s4Sx4MGW28bPFSSxmMMwaXW6A4zRTml8PL71oE67s3A20+vZNqUyEavCN dUnpSag6EYf2Xs19sJzrV1o0usVCzosSur3xw4cWMbiZXQo6DQQpvC9cz/Yfl01n/qAb0e rVb3M+HzTrWo8LBtE7xW1zW3CDmWh0bvVWi9tlU7SeVXBukuiWmHqHToZe0ZGw==
Message-ID: <c36eb9c7-c19b-4568-ad49-4c53f3ef9c9b@appelbaum.net>
Date: Thu, 26 Feb 2026 23:57:43 +0000
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
To: Nadim Kobeissi <nadim@symbolic.software>, Stephen Farrell <stephen.farrell@cs.tcd.ie>
References: <a5db938a-171a-44af-81db-25b8567324b2@cs.tcd.ie> <41B12991-3C53-4538-B736-6241824340C2@symbolic.software>
Content-Language: en-US
From: Jacob Appelbaum <jacob@appelbaum.net>
Autocrypt: addr=jacob@appelbaum.net; keydata= xsFNBFXlpJ8BEACnFzfarolZLsaP8GCk/ytNIUk6+GstAAVqQdHprkx3TfZl5/tUQC7a9oz/ +QD93U2Zq0RVj6/fAiZeV8X0TadVDcYo2KNk693EC1qwJwGMOMiYKEqAS1PuNSzQqvtyqlm9 0TrGL2qVKqIGHP1CXdV5QAlqqvpG5AVaH49H+cLmzkGdnz8Dp89zcmQ43EPvBxnHSq2P3D8+ aMgICQmzjxnqzX4X1w45EqNIv3STmTDS5HxhISu8KpRuWXvAm1XItCQGzJAq/ybEW60NpH4q yZsPQ74w6K3kECwEwUrO3yCScKuWFFs2qIdvditoWRIZQSErZi0VhMMoxx1n0y6dYffNvds7 c7j5n23KZ++8pZjqdql/cFez7o7RBn+tiTO5jJCFkhgDK51jQxec0d0qjeQvxCaafsM0q8qJ n8icW16yzOg5Ace6Hg+l+0DicqiwYYW1807xd+BGT4YqagdbtiB7UPcfEzAo84QlqYjqcKqT 3tKFf6SuetGffEW9f3XP9y19IqpNNRJDdWDrz44GeH86j/XE01buJE4evjvFaoUAGUYoB3Ul ZjtKj9bm1NpeKBmkgD1pqR4cWFf9tRJf31ztgd6PZBzuZ2fJkXShbz0wIVL+wDAX4X/fyUib OO1tgf9c+BYhRn8LTA9JtfAdm1YnscSK8pjLiD4u/Hbqk0H0WwARAQABzSVKYWNvYiBBcHBl bGJhdW0gPGphY29iQGFwcGVsYmF1bS5uZXQ+wsGIBBMBCgAyFiEE4R/M4wW5yEZ5Oweu2aEf fpkhXaEFAlXlpJ8CGwMCCwkCFQoFFgIDAQACHgECF4AACgkQ2aEffpkhXaHVCBAAhIJNeG8v q9SdwSmolgv4cqBOXYxuiH1GkZv4tbUHJfmg+msXFXY77Wd3G48ltM4srqCmfwGCGu2Y4Ggu iU3XQPwyQ7KU49WFU5s8ZFq0m/pt2chIlI3uvenvsxvS1GkljOrhpk/flkdtdqDb60GZizTZ JVnXMNuDmvTr97ltQ3q9vrp+tZv/+I02uhsWQGTQrSdCjOUYNtO3C4S/GSMDZ7Jzf6X89s1z /O7os4YCZx3qVxR9IsLqkFi/TyVsROOiIzea0oPifaO94Cg8kkEc9eYLfJwfIW7A67SLbiTd U4tkxT7o0SgAc0aHB24xZKkoLSVAXW/GyJlq/K8aB5Z3RYWibe4i4aCa/uJDaZwACLapU5pp botaM+yisguEZo/t10KGbkamwPHeaGi/UPLxUjR3TpeGWF31/xRe80vtVxaBCOy1+6W88UBH 3hFwb4mnH1jmZUKkjX0xAdzOf9ry7B/JLTsOSEoatj2IrmfNhM+66x9buLq8nPDbx4c3gfvd qcMbvkJDzGrGIF+dfhaGL42vBk69wziS6VL9eUZG6cDqL3yd+UqioFELV3n0I8NJR3QeOVkv nibez4PfpYvgvFiEf+0sPlUnEN6axrUdZNtKSm1+Lw7NSXVWwMHtNE9jn7fXaWIZ6thgHaoA ES5uVLQYwkpcHQ4UcUMuGGun2M7OwU0EVeWknwEQAL1jVf/pnmjEHYW7EGbhHy5C8lALekKt ubPT9/OPwY1rYXgjPYC9PMw0gTVpYVxotBRIY3NCay9Jsm5QtMX3EnkCP0dEv8EWU+o2WlEY JtwQFC/TQbwaKBaMgHWpUJFD07KdKMp/92CUMOMHEqToxv+TI+hidbRMRt/McYf0V9mrzE+5 KmQESfTSXPtV32LyslOMpeDIOa/XS816H2jtw4Mzb+VF0EdlqCvltovUIr0ghh4HSaOVQi8t bjax2F8NKM87yIhszsdneiDIH7Rk9ZznWfC5IMkLWCejPh1EZlU3zNzv+FFdDREaQ54SezE6 txW86UaBvwWUOAdgdYw6cDXBeAYfn90O6v96WxLUthfomAHb7kjTSG4ngOcoiOq/i/wOFryR G07bhL+WYA63hvqIM89DHfmhWhUsOkiUDbDK9xOABGQ7+UJ39r4IaNa4IUn/hSmyevncyJYJ MdjCDSruqmY4V34d3Q2cnAy+1jf8Cm4opOYdzAtuHNfjWLbXksO2z4mncee4NdKlpvD9rZCD 6iSEsdRV5UuiP8oBEi/4q1RNn8abCmyWUQXqdo3vnkV3Bgl8GnuS6GGEzVJq3pC8CqjZ97V/ +YHjgPcMUL2RCc9/QRfR71BjYsllLwlZtl85zYcbNORDUzVOe1Qg+k8DygcDPAuvFwLzLn1+ MGrZABEBAAHCwXYEGAEKACAWIQThH8zjBbnIRnk7B67ZoR9+mSFdoQUCVeWknwIbDAAKCRDZ oR9+mSFdoaX7D/49q6ALUSfwFyanXeX4YLfndeTCJd7AiGGlYVFzESkk4DUEy68Y8e7gYs4B 2YDpRzDgJrx2A61u7oSHv0b4hzwUJ41TyBbE4D2hR8o9qnAX2jpwWPinjCInbinUGkpfSZxn b7Yn6/p2kw5JeWGFlBJEyz3/g5ebq0qrx/OdpS9b8Jxlde3Le0jU+753BHV0ef3JfCTH6BuM 2T8Cv64n7vkhZWqUgnB3rEXIzq+xbYrpLJTeapwSr3k+xjI5YpmiTjUD8uCwzSJoq8x5YnXV CjA7TNGvhANFu1j5ElnSf4I6mje3gL+MK8Fw75SUZqdTL73rXstP2HqzDIV+19w8JA25h/Tm CcCYu717hq0kJVk2wiFbmhJHj6kb0tgn7xCCw9xe4g4T9K5YL4UiSpL+zxIb1BLuaYoYtPXP RcX0NkBu+N38Tvpng6HrBGFHQzTv4GB60eDm0A5+zbQe4RFmR5G1BdBpeYauNbtA9gAhuBZy DJPEu/qlaj3Ptk8MZiLFeHTZaBj9O1W8NuqK88k8KYkV/gd1Vni55bMee4CAhfGnHedDySGf mzbNFr/QAYmT3flZg7xnVJWSF904U8QAN1lejrC2dsj6TcaTHIzf9T3SZQDvc6e2ocYu6VeS Ctn4q1Sm/1ctbXEKhP8Ye1RRRwO0GvxJACvuHfoDqeZI98haZw==
In-Reply-To: <41B12991-3C53-4538-B736-6241824340C2@symbolic.software>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 8bit
X-GND-Sasl: jacob@appelbaum.net
X-GND-State: clean
X-GND-Score: -105
X-GND-Cause: gggruggvucftvghtrhhoucdtuddrgeefgedrtddtgddvgeejgeejucetufdoteggodetrfdotffvucfrrhhofhhilhgvmecuifetpfffkfdpucggtfgfnhhsuhgsshgtrhhisggvnecuuegrihhlohhuthemuceftddunecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenfghrlhcuvffnffculddqhedmnecujfgurhepkfffgggfuffvvehfhfgjtgfgsehtkeertddtvdejnecuhfhrohhmpeflrggtohgsucetphhpvghlsggruhhmuceojhgrtghosgesrghpphgvlhgsrghumhdrnhgvtheqnecuggftrfgrthhtvghrnhepveffudelgeeltddtlefffeeivedukeffveejhfffhfdvgfduueehteffhfekvddvnecuffhomhgrihhnpehnihhsthdrghhovhdpshihmhgsohhlihgtrdhsohhfthifrghrvgenucfkphepudelvddrkeejrdeltddrfeelnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehinhgvthepudelvddrkeejrdeltddrfeelpdhhvghloheplgdtrddtrddtrddtngdpmhgrihhlfhhrohhmpehjrggtohgssegrphhpvghlsggruhhmrdhnvghtpdhqihgupeelueekgfeigeduueehjedpmhhouggvpehsmhhtphhouhhtpdhnsggprhgtphhtthhopeegpdhrtghpthhtohepnhgrughimhesshihmhgsohhlihgtrdhsohhfthifrghrvgdprhgtphhtthhopehsthgvphhhvghnrdhfrghrrhgvlhhlsegtshdrthgtugdrihgvpdhrtghpthhtoheprhhsrghliiepgedtrghkrghmrghir dgtohhmsegumhgrrhgtrdhivghtfhdrohhrghdprhgtphhtthhopehtlhhssehivghtfhdrohhrgh
Message-ID-Hash: DQDKMFG4VOJ2KBJAF3FVSAGKCH7AN3Z3
X-Message-ID-Hash: DQDKMFG4VOJ2KBJAF3FVSAGKCH7AN3Z3
X-MailFrom: jacob@appelbaum.net
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: Rich Salz <rsalz=40akamai.com@dmarc.ietf.org>, tls@ietf.org
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/UwzHG5x1jdi1jyCxgKBno0qsxVA>
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>

Hello,

On 2/26/26 04:44, Nadim Kobeissi wrote:
> Dear Stephen,
> 
> Thank you for your note. I appreciate your shared reservations
> regarding the publication of this document.
> 
> I agree entirely with both you and Rich that a single participant
> does not possess a unilateral veto, and that assessing consensus
> requires judgement calls by the chairs. IETF procedures do not allow
> one person to hold a document hostage based merely on contention or
> preference.
> 
> However, there is a fundamental difference between a generic
> complaint and a substantive, detailed technical objection. As
> outlined in RFC 7282, the essence of rough consensus is that all
> legitimate technical concerns must be addressed—not necessarily
> accommodated, but technically resolved or refuted.
> 
> If a severe technical flaw is demonstrated, or if prerequisites—such
> as FATT review—aren’t met, and the Working Group's only response is
> to state that they "still want to move forward" without engaging
> with the realities of the flaw, then the technical issue remains
> unaddressed. Proceeding under such circumstances is not rough
> consensus; it is the administrative dismissal of an unresolved
> technical reality.
> 
> My objective is simply to ensure that the cryptographic standards we
> produce are sound. I remain fully prepared to engage with any
> rigorous technical refutation of the vulnerabilities I have
> detailed. Until the substance of those concerns is actually met, my
> objection stands on its technical merits.

I am in full agreement with Nadim and others on the list pushing back 
against publication of this draft. I find the counter arguments, and the 
motivations or rather the lack of motivations, to be unconvincing.

It is important to model and verify, and indeed to think about changes 
very carefully. It is surprising that the FATT review isn't the starting 
point for serious consideration.

It is prudent from a risk management perspective to use hybrid 
constructions with an appropriate combiner. Even if an attack against 
ECC were to be demonstrated tomorrow using a quantum computer, does 
anyone expect every adversary to have the same capability and the same 
datasets instantly? It seems unlikely, and various issues in 
post-quantum implementations seem to be much more likely to arrive again 
and again, and sooner.

Those who want post-quantum protections should not be less secure for 
hedging security concerns with the use of hybrid constructions. TLS 
enjoyers and myriad unknowing users should not need to take special 
steps to ensure they aren't accidentally using the less conservative, 
riskier strategy. The longer cryptographers and security researchers 
have to discover and fix various issues while hedging safely, the 
better. Those who only want post-quantum security are always free to 
publish their ECC secret keys as a sign of their confidence.

The compositional security properties mentioned by Nadim and others are 
table stakes for deploying post-quantum cryptography. The math, the 
various implementation details, and the deployment contexts that are 
secure today using ECC today should remain at least as secure today and 
tomorrow. Targeted and mass surveillance collection of data is part of a 
larger pervasive attack strategy that is practiced by many adversaries 
more or less continuously. Practical cryptanalysis of data collected 
through such surveillance or other means of data collection is by no 
means limited to a hypothetical quantum computer.

In the tremendous volume of email on list there has not been a 
compelling technical argument against hybrids to the contrary presented.

I oppose publication of the draft and furthermore think that for TLS, we 
should see hybrids listed as RECOMMENDED (i.e.: recommend=Y). In an 
ideal world with prudent risk management, hybrids would be listed as a 
MUST, and PQ only should be a MUST NOT[1].

With regard to Kyber/ML-KEM, NIST dismissed or did not address important 
technical concerns, and they ignored other related concerns of 
significance that were raised in the public comment period[0]. The 
effect of that overall disappointment has been immensely harmful to 
NIST's international standing, which was already lying down, to 
paraphrase a great American poet.

Given this experience with NIST, I oppose publication of this draft for 
another reason: it will further damage IETF's standing as an independent 
and fair forum that seeks to protect users and the internet without 
advantaging any Adversary.

Probably others have already received emails about this very WGLC where 
they have been asked if this will be an example of Project BULLRUN's 
latest victory. Exclusionary hostility and anti-competitive concerns 
aside, I am cautiously optimistic that it is at least possible that the 
WG and indeed the IETF won't be such an example (again).

Kind regards and happy hacking,
Jacob Appelbaum

[0] 
https://csrc.nist.gov/files/pubs/fips/203/ipd/docs/fips-203-initial-public-comments-2023.pdf
[1] Pure PQ in TLS, not even once!

> 
> Nadim Kobeissi Symbolic Software • https://symbolic.software
> 
>> On 25 Feb 2026, at 11:38 PM, Stephen Farrell
>> <stephen.farrell@cs.tcd.ie> wrote:
>> 
>> 
>> 
>>> On 25/02/2026 21:50, Salz, Rich wrote: You misunderstand what
>>> “addressed” means here. A perfectly reasonable response is “the
>>> issue has been discussed by the WG and they still want to move
>>> forward.” As another recent example, the LAMPS WG went ahead
>>> even though one participant (repeatedly:) raised patent
>>> concerns.
>> 
>> Despite me not wanting to see this document published, Rich is
>> correct here. There are always judgement calls required and one
>> participant being convinced there's a fatal flaw in something is
>> not sufficient in itself to block that thing. If a participant
>> convinces others of the fatality of the flaw, that may be
>> different, but if something is generally contentious, (as in this
>> case), a claim of a fatal flaw by itself blocks nothing.
>> 
>> Cheers, S. <OpenPGP_signature.asc>
> 
> _______________________________________________ TLS mailing list --
> tls@ietf.org To unsubscribe send an email to tls-leave@ietf.org

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