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

Jan Schaumann <jschauma@netmeister.org> Tue, 07 July 2026 19:34 UTC

Return-Path: <jschauma@netmeister.org>
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 467CF11253764 for <tls@mail2.ietf.org>; Tue, 7 Jul 2026 12:34:37 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1783452877; bh=EcJ8tongTXBzTOI3xcD4MDRIYDO1ADvbOfrJ+DQmNZs=; h=Date:From:To:Subject:References:In-Reply-To; b=ueXel4cTU4xjy+JWA93PHbfYNDllAYk11tFaST5iJuOZrWytFArSDLJGMD9rJwC+K Ux1GLvi/z0Dy9KecLc9bBWXv/+yohUZS+tQgHSGMoR0lNhvXCN1X/Lyp1GGbeQELub RTVSKsyNkjqwQ7I0V1NG7p96M6sYtC+zqIsL0L/I=
X-Virus-Scanned: amavisd-new at ietf.org
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level:
X-Spam-Status: No, score=-2.098 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_VALIDITY_CERTIFIED_BLOCKED=0.001, RCVD_IN_VALIDITY_RPBL_BLOCKED=0.001, 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=netmeister.org
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 mchvgjZCMyCo for <tls@mail2.ietf.org>; Tue, 7 Jul 2026 12:34:36 -0700 (PDT)
Received: from panix.netmeister.org (panix.netmeister.org [166.84.7.99]) (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 5D2A711251D1C for <tls@ietf.org>; Tue, 7 Jul 2026 12:33:09 -0700 (PDT)
Received: by panix.netmeister.org (Postfix, from userid 1000) id D6475A108D; Tue, 7 Jul 2026 15:33:08 -0400 (EDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=netmeister.org; s=2026; t=1783452788; bh=EcJ8tongTXBzTOI3xcD4MDRIYDO1ADvbOfrJ+DQmNZs=; h=From:To:Subject:Content-Type:From:To:Subject; b=pcmiSs6fzImCQXC5R0Nq3v5Q8wARPa7y55HukhjYElsOBZD72w7/ofmwom7DDOnIF jmKYiNNjqIGnckXdN0NLp/P1rXRph5BwcC43O4kwNAT69xTpg8dYcOxhXzVbmeps+A zhSB1n2fGvVPC0pGREO4kH2G6EcGdlVEp+3HG9HE=
Date: Tue, 07 Jul 2026 15:33:08 -0400
From: Jan Schaumann <jschauma@netmeister.org>
To: tls@ietf.org
Message-ID: <ak1UdBUYWqhuWqOM@netmeister.org>
Mail-Followup-To: tls@ietf.org
References: <CAEEbLAaA7vzcjt8GRNru-7RAGP=e_7NzeoLmHXbgwcFisT=GXg@mail.gmail.com> <EB201BCC-756B-4F27-9309-80EABA140931@symbolic.software>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <EB201BCC-756B-4F27-9309-80EABA140931@symbolic.software>
Message-ID-Hash: AB6OOCXRVHIVPIZUWJCKWZINTGTHAJKN
X-Message-ID-Hash: AB6OOCXRVHIVPIZUWJCKWZINTGTHAJKN
X-MailFrom: jschauma@netmeister.org
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-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/ATpVfPy2CekdjrK0R1ghud9RPsc>
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>

Nadim Kobeissi <nadim@symbolic.software> wrote:

> Sophie, your own coworker at Google, David Adrian (a product manager on Google
> Chrome) has *repeatedly* expressed on this list that Google Chrome, the world’s
> most popular browser, has (presumably with his encouragement) already
> implemented draft-ietf-tls-mlkem, without even waiting for the results of this
> consensus call.

Implementing it is not the same as enabling it by
default.

Several of Google's servers also support MLKEM1024,
but do not prefer it if the client offers
X25519MLKEM768.

I don't work for Google, but reading the tea leaves
strewn across the internet, I would hazard the guess
that Google puts in place the bits that allow, e.g.,
an organization administrator to _enable and prefer_
pure MLKEM much as they have signaled that they will
allow pure ML-DSA certs for private PKIs while
pursuing MTCs for the web-PKI.

That is, an organization administrator might decide to
set this for all clients under their control and then
know that for the services they control (as well as
certain services Google offers) pure MLKEM will be
used.

This is in line with Sophie's argument: there is no
chance of a pure MLKEM being negotiated
_accidentally_.

(For which of their customers they are putting this in
place is a different bet you can place.)

-Jan