IETF Logo Mail Archive

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

Paul Wouters <paul@nohats.ca> Fri, 03 July 2026 21:43 UTC

Return-Path: <paul@nohats.ca>
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 EA5D010E1EF98; Fri, 3 Jul 2026 14:43:38 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1783115018; bh=xdRgHKIxF8Cmow7Y7bLXRRs0fhZ7oVoB/f11AnueDjE=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=zMCeW8K7S/JIMQ/z0mAhZ3JKHEGTm44ea7LfitEovNRnJfkICj3jKp8MtN3T94sRT efh3t2Fo7fMOQ3zRDTO8qRobOkYJM3MyhYB8SAJpNOnc/9YWVkEp0E5geHtkuIXlYD KwOn2VBrTNTzcDh+w8d0Mw5Yz6w9yvJ/tbgy3VWw=
X-Virus-Scanned: amavisd-new at ietf.org
X-Spam-Flag: NO
X-Spam-Score: -4.4
X-Spam-Level:
X-Spam-Status: No, score=-4.4 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_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: mail2.ietf.org (amavisd-new); dkim=pass (1024-bit key) header.d=nohats.ca
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 1BTZxpj91HZq; Fri, 3 Jul 2026 14:43:38 -0700 (PDT)
Received: from mx.nohats.ca (mx.nohats.ca [IPv6:2a03:6000:1004:1::85]) (using TLSv1.2 with cipher ECDHE-ECDSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail2.ietf.org (Postfix) with ESMTPS id 03A1510E1EF91; Fri, 3 Jul 2026 14:43:38 -0700 (PDT)
Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 4gsS1P2Bkgz3Zx; Fri, 3 Jul 2026 23:43:37 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1783115017; bh=xdRgHKIxF8Cmow7Y7bLXRRs0fhZ7oVoB/f11AnueDjE=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=BN3SKV2+jyn+GDUW6SZ9ebuuT9akzab1r+b0sGsX1f1KDLvZM8NGi4qHIktonOEiu mahxeOaqSaRR9LbIJ0UPDTjWP868g1xXbF7i/KLlpb+EEuWWv/GRmjLhgo3Qrom2gV FJJBW9Xq21g7ip1f7iuCD0vHxpuAcVMM9dscTtOY=
X-Virus-Scanned: amavisd-new at mx.nohats.ca
Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id LT9t3fR8m9jU; Fri, 3 Jul 2026 23:43:36 +0200 (CEST)
Received: from bofh.nohats.ca (bofh.nohats.ca [193.110.157.194]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Fri, 3 Jul 2026 23:43:35 +0200 (CEST)
Received: by bofh.nohats.ca (Postfix, from userid 1000) id BB912191C32B; Fri, 03 Jul 2026 17:43:34 -0400 (EDT)
Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id B6B13191C32A; Fri, 03 Jul 2026 17:43:34 -0400 (EDT)
Date: Fri, 03 Jul 2026 17:43:34 -0400
From: Paul Wouters <paul@nohats.ca>
To: Joseph Salowey <joe@salowey.net>
In-Reply-To: <178231320760.1520243.5914961961176039994@dt-datatracker-f9b87776f-8pmmg>
Message-ID: <addea3e1-e8e3-dbd2-2b2e-a7dbc99e10b6@nohats.ca>
References: <178231320760.1520243.5914961961176039994@dt-datatracker-f9b87776f-8pmmg>
MIME-Version: 1.0
Content-Type: text/plain; format="flowed"; charset="US-ASCII"
Message-ID-Hash: XWR4RK4IW5JF6OQ3TCGOULZWHMD4FISH
X-Message-ID-Hash: XWR4RK4IW5JF6OQ3TCGOULZWHMD4FISH
X-MailFrom: paul@nohats.ca
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, tls@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/0jI86KN4XcH0vaa6rU8DRTM_jeo>
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>

On Wed, 24 Jun 2026, Joseph Salowey via Datatracker wrote:

> 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:

I support the publication of draft-ietf-tls-mlkem-08.

There is a clear demand from some communities, including global SDO's.

The algorithm is well researched and secure (See https://keymaterial.net/2025/11/27/ml-kem-mythbusting/ )

When quantum computers become prevalent, this would become the algorithm
to migrate to, as hybrids will lose its seat belt capability. So it is
healthy to have a clear stable RFC backed code point baked into software
and available, to allow different people to switch to non-hybrid based
on their own personal risk assessment.

No one is mandated to use pure MLKEM, and the IETF consensus of preferring
hybrids is made clear via the TLS IANA registry.

Previous discussions saw three groups of people. Those in favour,
strongly against, and those opposed because it didn't clearly state
concerns. I notice this last group has mostly cleared their objections
with the -08 draft version.

Previous attempts to set policy so all algorithms would not get an RFC
but just a code point failed, so this algorithm now shouldn't be the only
one not getting an RFC number, as that misinterprets IETF consensus. The
arguments for getting an RFC number are the same reasons as applicable
to others who got an RFC and the same reasons for the lack of consensus
for withholding RFCs for all algorithms. That is, whether we like it or
not, vendors use (IETF stream) RFCs (vs drafts or ISE RFCs) to determine
stable code points worthy of implementing. Other SDOs have policies
requiring RFCs for supporting features, some opensource libraries do
not write or compile in support for non-RFC items.

The people who claim that pure MLKEM does not need an RFC seem to overlap
strongly with those who said the SSH NTRUprime+X25519 hybrid, despite
being massively deployed, still absolutely needed an RFC number. It
seems this argument is not used objectively in IETF discussions, but
more as stand-in argument to get one's own preferences codified.

The IETF facilitates interoperability via internet standards, and should
not take on the role of the Internet Protocol Police.

I am very concerned by the consensus-manipulating efforts of the previous
WGLCs that continue into this current WGLC, such as via social media
influencers and via the filing of infinite appeals which have all been
denied after time consuming procedures.

Paul

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