IETF Logo Mail Archive

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

Nadim Kobeissi <nadim@symbolic.software> Thu, 26 February 2026 03:44 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 1054FBE6C270 for <tls@mail2.ietf.org>; Wed, 25 Feb 2026 19:44:32 -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=unavailable autolearn_force=no
Authentication-Results: mail2.ietf.org (amavisd-new); dkim=pass (2048-bit key) header.d=symbolic.software header.b="pQ+8xZHB"; dkim=pass (2048-bit key) header.d=messagingengine.com header.b="vv1/f3uG"
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 WiVWLRQsRweb for <tls@mail2.ietf.org>; Wed, 25 Feb 2026 19:44:30 -0800 (PST)
Received: from fhigh-b6-smtp.messagingengine.com (fhigh-b6-smtp.messagingengine.com [202.12.124.157]) (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 659D7BE6C260 for <tls@ietf.org>; Wed, 25 Feb 2026 19:44:30 -0800 (PST)
Received: from phl-compute-02.internal (phl-compute-02.internal [10.202.2.42]) by mailfhigh.stl.internal (Postfix) with ESMTP id BA5FC7A013E; Wed, 25 Feb 2026 22:44:22 -0500 (EST)
Received: from phl-frontend-03 ([10.202.2.162]) by phl-compute-02.internal (MEProxy); Wed, 25 Feb 2026 22:44:22 -0500
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= symbolic.software; h=cc: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=1772077462; x=1772163862; bh=TgIRyju06U dXhRcWi1C52YqqO5lzGfLLR93ElxWFJjg=; b=pQ+8xZHBCO+KyhZBN42cMdBLHk eilGQ0sW3Mq+z5mzpa7xre7Kc1Ue5UiuMtdDMbP9QYql0g7nSnPCiCJvRZRsnD59 HrlaTZ604vS4Me21mluaJsf8X5uFvCZBY2/LtmhLbT6+1EL1+JyuMZSyFvxZpL6V gaxy/3A5dMdF1k3/bQr+qxpR19wGYseeXCTVWCcT6WVEThZO0RTgVdLLbAxim3Ku QNlGSUvpxbuuGo/DboA3UxSlK/dfxGwZIYjuUOfHRJZLb4VD/rix8duxXgvwlb2p n+LIrBIo2PNzna4NPE2LBOHD2YYHgmw0e0EWOQpL6obhdZNk0EP1VwhIrwtg==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc: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=1772077462; x= 1772163862; bh=TgIRyju06UdXhRcWi1C52YqqO5lzGfLLR93ElxWFJjg=; b=v v1/f3uGtS1BK28MwHBLFuY12ZbS0UwAk4E3A8uPy7uylVnClXY7zDCD+Oy4SeR7B GolhHcmZcsDr92U7l52GEdZp7s6Bvbt4M4ziJ4zSlHyw8p/k7VgbAtoUOiMaVF41 quHLgqvbn99Rwlw9us0EmKhV6cq2oOt1gClJoj7m/nGk0EbPJSWqIXMoqbMZNq2r LkONcNVX/SvVdG8qtrNKCbZLAI3K8+Ya3ot7+2yBrPu6lzSEeEyQLKuuCQRzVGwb +0dCYGl6zyb+SbxoUuZR+yL+kFr97kwXvSuhaHK5kOdSmTw021H8H/kZ8azWxMTg gzZ7U6elTfev+r5+U863Q==
X-ME-Sender: <xms:lsGfaXkmoTv8wjNY9I8bchpsp1jiGzV6wQpOvmqFnsQStrH17t-XGQ> <xme:lsGfaSmbhHpK78xgvtdI4PUlCsSM9svah7VDCayNgfZnCAVsLYisstXXuB6x9O-nu R-oEpR4sxm4_D-r0BjxUjoIwIcBG6YuQ9ee4EyH_W7Cp6lCgxa19w>
X-ME-Received: <xmr:lsGfaQtiClBs2I7XGsxLmdDuXvQI_F5y9tBl6Pf6Mks_EDYHDza30Zu3JJQRy_3U1n3kQ_BF6SXoN_qk93h8ZSXi4P6DTDnGz9D8I9uTSIquMGe-ynR27Y8ZUw>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeefgedrtddtgddvgeegleejucetufdoteggodetrf dotffvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfurfetoffkrfgpnffqhgenuceu rghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmnecujf gurheptgfghfggufffkfhfvegjvffosehtqhhmtdhhtdejnecuhfhrohhmpefprgguihhm ucfmohgsvghishhsihcuoehnrgguihhmsehshihmsgholhhitgdrshhofhhtfigrrhgvqe enucggtffrrghtthgvrhhnpedtfffggedvfedutddugfehtdfftdejudetgfegvefhteel vefgvdekheeijeetieenucffohhmrghinhepshihmhgsohhlihgtrdhsohhfthifrghrvg enucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpehnrggu ihhmsehshihmsgholhhitgdrshhofhhtfigrrhgvpdhnsggprhgtphhtthhopeefpdhmoh guvgepshhmthhpohhuthdprhgtphhtthhopehtlhhssehivghtfhdrohhrghdprhgtphht thhopehrshgrlhiipeegtdgrkhgrmhgrihdrtghomhesughmrghrtgdrihgvthhfrdhorh hgpdhrtghpthhtohepshhtvghphhgvnhdrfhgrrhhrvghllhestghsrdhttggurdhivg
X-ME-Proxy: <xmx:lsGfadkhN19rMpQ7WbTvCMDS7ymg4hgAyZj8hUbF1lwoh1cX3OxBQQ> <xmx:lsGfaTtpweJkrn2HLiE6_RvcHIj0KonND1ww5ORDqFSu4VeaIl34bw> <xmx:lsGfabeQd-A3IU6MF94TD-CEnsIfTN0lH_yXsSgnamn3FGXa4EaHsw> <xmx:lsGfabwVi4cuH2EvemOfPOqHpg0llvOWx1sc840b8NlQm-LMMYyJHg> <xmx:lsGfaQCxO10MYLN-3ifB66gsnviI64ekNjAneR6aPX_hOrIxaAbd6bj7>
Feedback-ID: i6d3949ed:Fastmail
Received: by mail.messagingengine.com (Postfix) with ESMTPA; Wed, 25 Feb 2026 22:44:21 -0500 (EST)
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
From: Nadim Kobeissi <nadim@symbolic.software>
Mime-Version: 1.0 (1.0)
Date: Thu, 26 Feb 2026 04:44:20 +0100
Message-Id: <41B12991-3C53-4538-B736-6241824340C2@symbolic.software>
References: <a5db938a-171a-44af-81db-25b8567324b2@cs.tcd.ie>
In-Reply-To: <a5db938a-171a-44af-81db-25b8567324b2@cs.tcd.ie>
To: Stephen Farrell <stephen.farrell@cs.tcd.ie>
X-Mailer: iPhone Mail (23D127)
Message-ID-Hash: MWD44BLLFYNCGDR3MVB7IW4O2JQUKAY3
X-Message-ID-Hash: MWD44BLLFYNCGDR3MVB7IW4O2JQUKAY3
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
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/AGMb2WWsVDnDP4tJkegXkUHsxjc>
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>

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.

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>

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