[TLS] Re: WG Last Call: draft-ietf-tls-mlkem-05 (Ends 2025-11-26)

Viktor Dukhovni <ietf-dane@dukhovni.org> Sat, 28 February 2026 07:55 UTC

Return-Path: <ietf-dane@dukhovni.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 037E6C0439D4 for <tls@mail2.ietf.org>; Fri, 27 Feb 2026 23:55:47 -0800 (PST)
X-Virus-Scanned: amavisd-new at ietf.org
X-Spam-Flag: NO
X-Spam-Score: -4.398
X-Spam-Level:
X-Spam-Status: No, score=-4.398 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, 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=dukhovni.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 tPbBkVOQSHlI for <tls@mail2.ietf.org>; Fri, 27 Feb 2026 23:55:46 -0800 (PST)
Received: from chardros.imrryr.org (chardros.imrryr.org [144.6.86.210]) (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 EFB04C0439AD for <tls@ietf.org>; Fri, 27 Feb 2026 23:55:34 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=dukhovni.org; i=@dukhovni.org; q=dns/txt; s=f8320d6e; t=1772265331; h=date : from : to : subject : message-id : reply-to : references : mime-version : content-type : in-reply-to : content-transfer-encoding : from; bh=wJVliyG5ItFpGuCmMqJQf32anDlYlsFuadJEcGVCFLY=; b=zMBBU3TAC4d/ZpjToDTqIAd2M/TgYKa5Kwfn4NLN1HT8pIxtlvSvQ5QCHSy2glwGbS2Np Zn0HFN7Fl49Me7EmBg8P/AEcJA8NkYyCLv+Wpgm/xj58Vmp0ZFUhO6yBHQycaBBwyFBqSU1 N1KWzJIdHtVa7bPWiNkFK8h8t9QTE4M=
Received: by chardros.imrryr.org (Postfix, from userid 1000) id AE12F938E14; Sat, 28 Feb 2026 18:55:31 +1100 (AEDT)
Date: Sat, 28 Feb 2026 18:55:31 +1100
From: Viktor Dukhovni <ietf-dane@dukhovni.org>
To: tls@ietf.org
Message-ID: <aaKfcxMUQCjL5rxg@chardros.imrryr.org>
References: <GVXPR07MB96788602130757CA20A7A43B89DFA@GVXPR07MB9678.eurprd07.prod.outlook.com> <6e64794b-f257-4faa-9419-fe6ccd6bf294@cs.tcd.ie>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Disposition: inline
In-Reply-To: <6e64794b-f257-4faa-9419-fe6ccd6bf294@cs.tcd.ie>
Mail-Followup-To: <tls@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-ID-Hash: PFKJJO2SRCVFRIF2ZBEONASPGFEKAO6H
X-Message-ID-Hash: PFKJJO2SRCVFRIF2ZBEONASPGFEKAO6H
X-MailFrom: ietf-dane@dukhovni.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
Reply-To: tls@ietf.org
Subject: [TLS] Re: WG Last Call: draft-ietf-tls-mlkem-05 (Ends 2025-11-26)
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/1p3CAQSpdb89KMbphFTxZpbPkLs>
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 Thu, Nov 27, 2025 at 07:43:57PM +0000, Stephen Farrell wrote:

> Hi John,
> 
> On 27/11/2025 16:02, John Mattsson wrote:
> > - ML-KEM-512 is the only adopted quantum-resistant algorithm that
> > can be used to bypass legacy middle boxes.
> 
> Do you know if anyone's written up a description of that?

Though some SMTP servers (often noticeably slower to upgrade than the
Web), problems with multi-TCP-segment ML-KEM client hellos have been
reported by senders to a few receiving domains, such reports are fairly
rare.  One notable problem site (at the time "boeing.com", was promptly
remediated).

I am inclined to be sceptical of the claim that middleboxes are a
significant barrier to adoption of MLKEM768.  If necessary clients can
include X25519MLKEM768 near the front of their supported groups list,
but without sending a corresponding predicted keyshare, and then at
the cost of an HRR negotiate its use with just the servers that support
and prefer it.  This is the approach taken in the default settings of
the Postfix SMTP client, where admittedly an accasionaly extra
round-trip is not a concern, and in any case server support for PQ key
exchange will be fairly rare for a while.

-- 
    Viktor.  🇺🇦 Слава Україні!