IETF Logo Mail Archive

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

John Mattsson <john.mattsson@ericsson.com> Sat, 29 November 2025 08:01 UTC

Return-Path: <john.mattsson@ericsson.com>
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 0A65B92585A0 for <tls@mail2.ietf.org>; Sat, 29 Nov 2025 00:01:42 -0800 (PST)
X-Virus-Scanned: amavisd-new at ietf.org
X-Spam-Flag: NO
X-Spam-Score: -2.096
X-Spam-Level:
X-Spam-Status: No, score=-2.096 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=0.001, RCVD_IN_VALIDITY_RPBL_BLOCKED=0.001, RCVD_IN_VALIDITY_SAFE_BLOCKED=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no
Authentication-Results: mail2.ietf.org (amavisd-new); dkim=pass (2048-bit key) header.d=ericsson.com
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 I2B5TNYIS7nY for <tls@mail2.ietf.org>; Sat, 29 Nov 2025 00:01:40 -0800 (PST)
Received: from AM0PR02CU008.outbound.protection.outlook.com (mail-westeuropeazon11013016.outbound.protection.outlook.com [52.101.72.16]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-384) server-signature ECDSA (P-256) server-digest SHA256) (No client certificate requested) by mail2.ietf.org (Postfix) with ESMTPS id A53DF925856D for <tls@ietf.org>; Sat, 29 Nov 2025 00:01:40 -0800 (PST)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=FkZrihYqA7Pi5IXSR25kDpciIVEaKNr1rjgY2/MAkyt6vvcvMPblonG9YBReO70XA4NpxhpiRfloLKhazIukDmN286qExtDIvTkgexnjyeVkl/AL/2PfDjA1Xl0B0Yr7uBxXsAlRNfyx4yH4pPmv0CkMmYilwYaLJ/KocpnLglKBmR1AKY/7hqpsiM72a6tIwueztRMRVx5NbGgofg+z/BB7yLsPAYvB4CaAw/UmYcvgawe7bTjuntKOHsQ8PHyGE182InwoeBw9G51lpvajtB/yyF+ithJ+zgP00rEu1AuiIWxbEMenz47/m9wLKlxE0QEGWAyvh7Vvjnt7l/ZrDA==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=H+KAvPv0DsgeZDBtwj4bmAUuihvitQREsM53khSo+XY=; b=ykvOkI53B0WGxM/C/VuhYRZKur8gDH21g2b+K75P8nYTun8rNCf2GO4v9rpAG+nUK5N2bWKj59IMraKLkj39uaVhW39wQfVQTt/MfE+weAyK0BRvxGZnmS9I0MXrOz4H7RJffmc2AGy/tqQN7gNeESB3qZd+iRMMYENuTme6nMnL6ota5Mp1n5q/GAywFBzKJq1JANvxZaBNsX+lXbmdalE9OZxnTw1p7wZDzP2JxEnykuvxYfuvbB6xogvwkEcCAP2DTq2xw4vyDCLKgjqzjHv/0t1W83AIyX6Os2/3Y58vOlx1JVbRuIqn9QSZKGx2DevjY8Dg+mpExqHdAl7TJA==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=ericsson.com; dmarc=pass action=none header.from=ericsson.com; dkim=pass header.d=ericsson.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=H+KAvPv0DsgeZDBtwj4bmAUuihvitQREsM53khSo+XY=; b=ukohdU+PSf7/8GpfudDVjhhPAUbkD5egkOnCVo+neltcz3oKlneBCcxV/qRn8+MRwEBid03HJqQLiK4co/KfBag8TtNiRdvYAzDHpIO6xbewjDlEgeeNN1PXaF3RDXOJDl5LeAAumUVVpwBlUqTj8KGjJ/+NsaB0QTWNchs3egDqKI+9GGzZKc9991M+1yHuDrTbk6QGYS/W51gsUyaSSsWQsD20m1MlIrv2L1j5RcYC0r1mpEWG2Zi4ltMvzOKoIbX0kG5zgNKpbUu0wBxVTXxMg4Pb0p9yE0n6mtRke8CtCigB1bTF4iKOQxfXehXlnXol5u/zbCox+V3yyy1bSg==
Received: from GVXPR07MB9678.eurprd07.prod.outlook.com (2603:10a6:150:114::10) by DBBPR07MB7596.eurprd07.prod.outlook.com (2603:10a6:10:1e0::18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9366.17; Sat, 29 Nov 2025 08:01:33 +0000
Received: from GVXPR07MB9678.eurprd07.prod.outlook.com ([fe80::bcf3:3f45:888e:a4b8]) by GVXPR07MB9678.eurprd07.prod.outlook.com ([fe80::bcf3:3f45:888e:a4b8%3]) with mapi id 15.20.9366.012; Sat, 29 Nov 2025 08:01:32 +0000
From: John Mattsson <john.mattsson@ericsson.com>
To: Bas Westerbaan <bas=40cloudflare.com@dmarc.ietf.org>
Thread-Topic: [TLS] Re: WG Last Call: draft-ietf-tls-mlkem-05 (Ends 2025-11-26)
Thread-Index: AQHcYDCeQBPyhE37cE2C33OwvtXsX7UILXOAgAAeH2KAAMHXAIAAPlI2
Date: Sat, 29 Nov 2025 08:01:32 +0000
Message-ID: <GVXPR07MB9678611D40CB948FA27D911989DDA@GVXPR07MB9678.eurprd07.prod.outlook.com>
References: <GVXPR07MB9678B44C77FACE5495ABD97789DCA@GVXPR07MB9678.eurprd07.prod.outlook.com> <CAFR824xWR2xQmTF20JKyFc-wDoOSYHCc-MLizqV5MABTGBwcxQ@mail.gmail.com> <GVXPR07MB96789138C31A816AA0E5CA4089DCA@GVXPR07MB9678.eurprd07.prod.outlook.com> <CAMjbhoVpZJ-8HJdSK46eSyDFX=bYdMGv7oXeOaf8JipqNOCw6g@mail.gmail.com>
In-Reply-To: <CAMjbhoVpZJ-8HJdSK46eSyDFX=bYdMGv7oXeOaf8JipqNOCw6g@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-GB
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-ms-reactions: allow
authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=ericsson.com;
x-ms-publictraffictype: Email
x-ms-traffictypediagnostic: GVXPR07MB9678:EE_|DBBPR07MB7596:EE_
x-ms-office365-filtering-correlation-id: ae71f942-021f-4355-41d2-08de2f1d82ce
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-relay: 0
x-microsoft-antispam: BCL:0;ARA:13230040|366016|376014|1800799024|4022899009|8096899003|7053199007|13003099007|38070700021;
x-microsoft-antispam-message-info: 1Eea1vx62k9MQFW8SmBEX2C8w9WDtnSVACJgvNgSaypuGiEDJvi1Jqu4T4t65qpPSMAgGifcRkdJo7WRN5HPW+j5b9ulXPbsXkPcRillDg945NE+ymG55yw4ggCuvvHXJRwtLXzYlgEzw3V2ySGkujt7vQJ+ofKOq8M0aoEH/IWvUm2USB/7xYjUp5pi2JBG0Mfv80ErkN262AACx4jDoSQeg+Bd3EX70D6plE8n0P5t/YS10kwDusaNuQKZZt7u7mwWyEjpJ/9fIAJSPTrXB2sH7rrwrF/aYlDAiNqz+5eUgy1LrwO6SF49xTFidpqBx0ASqJSFf/WZ2C326STdAe0qc0pHPpLOZhcau2XhrNG2zV+wHpYtnW7Kkk8mcEuKw9+W2vvXIQUwMnq3wyB7NyPaGyP3FeOi+ATroTeFPoI5Bj0S6HjM4Pv7xvqccOt2IXgvSUtZ7ehQRuMEcVXk+5INUpxmXAJ6TFlI16vXcgA8nrVoRZ+5mTcheEr046D+LsRyOqIu+Vew3sl8kQvIxeEDkustAu5dS1tAZZIrTDC7une4bnIkFvw2lEQFKLgzlIcwPLVTmXRxe0wrVAcPcGhECm0LOZTfU0bEQMRIXIKf9EMxwioQo0v7vL0216xikz3Tnsoartj5NpCDsu+UvPhBMglorLQr/sCEoXX4k/JbZaz2hJHH0DYNahbLWLi+g//GxsNz6wNmJlgwVwVufsBPHyZflbeN7OKX38FEb4K1DHQq+K/srGTFB7hlsjyZ33mJexRRRX1tmI3by49c+zkLHDUUM8SNGYsz8csdOxJy/tRgrqGnkY7yXJ3RM15yXJh2y+b9xbXqseTKWp447Nk6CZnzPk5gTvzUd9pQJw+qfMh/7Wl+v0WwgeaHaIXbAeB+hGJqeDkIrVcFhR6mNblx3J/UaHZYspkkQEseguvziXbFgXBpV6THZayMc8hZsnDhX/9CeHs4Mt58E1S0kaVBEdmec1GBxmPWabtNSMpTpFSg7krbQxu9v0i9IDBfsW6sV8fEpVlCJyVhqKYbCGStJ3Z1J0wmPOwwDoM17XCsg9YRRXfiyeyx6H6LxXiAtRDraJ6y9eFkWVoVuYnKAPCjh0AGYLOcPxdk0fm8YQJaE4VDx2zQfsXZfCodJppnj0M1P7GeGYeEf2QvPE49YFNFlCvQe6rSbhQz6NMhCO3RjYXg+G/gBD8cZxQXT0Nv+8jZsghUwXKmiGbSwFWw1A4/TdYjBZ+CHLBWqpi3Xwi6DZbrXmx9K/NTg8SwZx/Bnejjxw+rs0J/fSn917ar56Sd6O410o+U28mYV5bnXN+FIJkkwkSX62/+Dk6rqO5EhrgUMi7V2xriIyCfKmeu4JgOEpu4IRolaV3BxF8SdzwQMHs/AoQfzCDfWkUCoVVMNtLC/jZCuwsOsBMUAi7nQcF1EUzKyGZoomlGzabAFiaOKfepJvNqX6Haeg8mniyT
x-forefront-antispam-report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:GVXPR07MB9678.eurprd07.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(366016)(376014)(1800799024)(4022899009)(8096899003)(7053199007)(13003099007)(38070700021);DIR:OUT;SFP:1101;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0: v2QKYvfMYtd3Pdx9BOR5E6XL8J/10QVbRAjgcvpA9JEyze2UBiVv+Z2f73qv9v1HyZtFynNs8tc8GFav2lDvCDEq65EGVojX1pVUsy/mXYSn0hph1Ytv9Pbr5GtB78Ga92EsBCGXuXASY5omL/iSvUuS5ZufxOvtLaLtuTwEs6vqZLO/rvK81W4oEBun5sx1LY6I2ia2uvM6336UQxgNm/nofmQTYBNGQfjiketCHJgKpUKuwVEQxgC0Gyj8acBbgK3I3QcYnlFnRg3/yupbNQurmWR57X38eGuPTp1Qo0XYM6KwkaXfj+DI03bh8V4ycTFTQFPjE3G4FDuBELpjPTQBDhjrTgKXbK6QDGaXsLC1oeMUfmC5gdbZssUr+CL2T3oe0bAfv1bAzC5ufUXzikhBKAHc6DrRe3Rh8e9e2OfLgyE7P3yuLryIRSXBeMOhjFbhP+vkMi5mztIuW9ZzVpS4UAn9KkeS1RAs3tQnckLBGjzOGUCXiiGeEwc9a4VD6Klc2xwsAgFZmEjM+/WTrKbXtcAtrU8VABphJZVHrX3GCv4xk+CuPk68FfJLVtM3DrbfZUT6WU+5ZB3x2ceQMw1O73fT6l77AqrGvvg1yQ8iroI9o2dwtDB8Qq/W4oEZVqX7Zp521FllaNWSxbx0053B4A+A5cvg757awmThafa6E0d2T91MF8vtaDRASoDJdPVtTzv2EW1aWgy4sCR5sK5Iz7KkeW9sh9xlqKTgZZjXsm+yu/iPV3OSpp7gfYd6uaUZVgHVI8ty0U1GeW6jxWQz92JgHjeq8IWvpGydbAZYwS5vOznI4xpGCrJXSiZLX/EoiGCYQ34ZDSBBNxKptM+sdKahxD2VNaeOJLcwMHuSc1GUAbfA2IvqQgzSjDbb+zgmYI9VEJtklLHrQ86TuI+K14kLwTdGPZRuuj18bLQmGmR1yY4ijVGQ8GfDoz7F0zQUc1Aw6EuMHauAyL0jeFw8L8edK/rWs5m1NVqkfBgTzVUYCR24PjuP2QQ4Wauwtjc6aY9Sb8J1jA574W66DWyLiz+ryXuH5zJQPqoRomv4G5lAdPQSe0xzJsaS/xhWPFW45CYJedPikNihemgTruJhl8iPB4ANo9V+dOCe+3WntyB5E08IC5QDahrfLJ+k0F0hP8jn5KN6tdcjSZwHwDsCuB+LG3kb1bl63BegfwAg7VV0s3QZdCTDDPiWvcpiaceFsqHKidXgQCdHdO01A9GA4zcqIDv/b0cwSvq+lDGeRaWHcZGV4S+MynF1ExyE1c2Lic2FdUB2s3y+NSAHWOedPT8P4rSsNTu6EUTnQcRBdDXY8dq8HowaoZYNc3yp2NIsTVKLr6b919whJv0Jn6VpUxFLSvAew1D+zI4dSN3+XMQndXUYHLLuKsFUbtuNkqDHIDmPIHvWXs9krpfWH3gQL3d48zz0Y+dGfrX2dTp/rxnCGNbyxXULqoQU/PNlQXsyEQ1Q1uzApOaa21BoqLSID3Y9m6o0J8XmnpnpkqVn7cbG5gMw14DwNO5Wqy7brgXsazUlyrtu1qh2g+x9TgweSRRefwfjEnnv91C1V1T9ubG4Pe6Ey9yb1DftXVKKSNuHdpEopcPyAou0fXoKrGubNEepHcyc6DBJ6iHoVHc=
Content-Type: multipart/alternative; boundary="_000_GVXPR07MB9678611D40CB948FA27D911989DDAGVXPR07MB9678eurp_"
MIME-Version: 1.0
X-OriginatorOrg: ericsson.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: GVXPR07MB9678.eurprd07.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: ae71f942-021f-4355-41d2-08de2f1d82ce
X-MS-Exchange-CrossTenant-originalarrivaltime: 29 Nov 2025 08:01:32.7977 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: hgq+r5+q6qCHwPV8mxvuUvJk41lzy5DY949fGKQ7KpdUI1/iwXkgBLIMpas3vjqo24zwtJsH3o8h7FfYtJLh6fDC0hr3Gyso+guyzIsC7Do=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DBBPR07MB7596
Message-ID-Hash: 2NVSVATNVDV5RNIKC3HRNWGKU2AW4MDD
X-Message-ID-Hash: 2NVSVATNVDV5RNIKC3HRNWGKU2AW4MDD
X-MailFrom: john.mattsson@ericsson.com
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: "tls@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 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/2EuxZtWV6YlhGGF6tL2OvROyevs>
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>

Our "environment" is complex, there are thousand of operators, and the networks look quite different, from private industrial networks covering a single mine, to nationwide public operators serving millions of people, to government mission critical networks for first reponders. In some deployments we supply, integrate, and manage most of the equipment; in others, our products are integrated and operated by third parties. Internally we also rely on multiple TLS stacks, including our own Erlang TLS, OpenSSL, and Go TLS in Kubernetes, among others.

We are planning to use HelloRetryRequest. As soon as we started testing X25519MLKEM768 we ran into problems with many legacy servers that did not support fragmented ClientHello. Thanks for the idea the HRR also solves problems with middleboxes. But HRR is only a short-term solution, long-term I would like to not support negotiation of standalone ECC, and a client advertising suport of X25519 and then closing the connection if that is actually negotiated is not very nice and to my understanding not compatible RFC 8446.

Cheers,
John Preuß Mattsson

From: Bas Westerbaan <bas=40cloudflare.com@dmarc.ietf.org>
Date: Saturday, 29 November 2025 at 05:16
To: John Mattsson <john.mattsson@ericsson.com>
Cc: Deirdre Connolly <durumcrustulum@gmail.com>, tls@ietf.org <tls@ietf.org>
Subject: Re: [TLS] Re: WG Last Call: draft-ietf-tls-mlkem-05 (Ends 2025-11-26)

I know John is not talking about the public web, but I would like to mention that there we do have fragmented ClientHello even with ML-KEM-512.

John, I'm curious: how well is the HelloRetryRequest flow supported in your environment? That is: advertise support for X25519MLKEM768 but don't send it, and then have the server ask for it using HelloRetryRequest. In our experiments to origins, we didn't see any issues with this flow and enabled it by default. We did see some servers that do not support PQ also not supporting HelloRetryRequest (to a non PQ curve they do support). Hopefully this is just a server side problem and not a middlebox, but we can't tell that apart just yet.

On Fri, Nov 28, 2025 at 5:45 PM John Mattsson <john.mattsson=40ericsson.com@dmarc.ietf.org<mailto:40ericsson.com@dmarc.ietf.org>> wrote:
I missed that Meta used ML-KEM-512 as an optimization. My interest was for middlebox traversal when connections using X25519MLKEM768 are dropped. In those cases, the fallback options are X25519 or ML-KEM-512. Today it could be argued that the risk of implementation bugs in ML-KEM is higher than the quantum threat to X25519, but that balance will shift in a few years. My interest in TLS is internal telecom networks, not the public Internet or enterprise environments.

I hope I am wrong, but my expectation is that some middleboxes blocking X25519MLKEM768 will still be around in 2030–2035, when I would prefer to phase out standalone ECC.

John

From: Deirdre Connolly <durumcrustulum@gmail.com<mailto:durumcrustulum@gmail.com>>
Date: Friday, 28 November 2025 at 15:57
To: John Mattsson <john.mattsson@ericsson.com<mailto:john.mattsson@ericsson.com>>
Cc: Stephen Farrell <stephen.farrell@cs.tcd.ie<mailto:stephen.farrell@cs.tcd.ie>>, TLS@ietf.org<mailto:TLS@ietf.org> <tls@ietf.org<mailto:tls@ietf.org>>
Subject: Re: [TLS] Re: WG Last Call: draft-ietf-tls-mlkem-05 (Ends 2025-11-26)

> Yes, Meta has a good article on the topic

> https://engineering.fb.com/2024/05/22/security/post-quantum-readiness-tls-pqr-meta/

This is a good article— I want to highlight that Meta deployed Kyber/ML-KEM-512 only on their internal connections, and don't seem to have any plans to roll that out to their external connections. While -512 nicely fits existing infra, and I agree it should be available especially for IoT settings and internal deployments like Meta's, in general public internet settings it seems to be a a little riskier as a right-on-the-line parameter set for NIST Level 1 security than say -768, which has more headroom security-wise.

On Fri, Nov 28, 2025, 2:17 AM John Mattsson <john.mattsson=40ericsson.com@dmarc.ietf.org<mailto:40ericsson.com@dmarc.ietf.org>> wrote:
Hi Stephen,

>Do you know if anyone's written up a description of that?

Yes, Meta has a good article on the topic

https://engineering.fb.com/2024/05/22/security/post-quantum-readiness-tls-pqr-meta/<https://engineering.fb.com/2024/05/22/security/post-quantum-readiness-tls-pqr-meta/?utm_source=chatgpt.com>

There has also been quite a lot written about middleboxes, load-balancers, and other software that assume the ClientHello always fits in a single packet. See e.g.,

https://blog.cloudflare.com/pq-2025/
https://www.ietf.org/archive/id/draft-reddy-uta-pqc-app-07.html

Just looking at the key share sizes, it is quite easy to see that you can use ML-KEM-512 (800 bytes) and would have been able to fit X25519MLKEM512 (832 bytes) and still fit ClientHello in a single packet. It is also quite easy to see that it for many PMTUs it is problematic to fit ML-KEM-768 (1184 bytes) and X25519MLKEM768 (1216 bytes) in a single packet.

https://datatracker.ietf.org/doc/draft-ietf-iotops-security-protocol-comparison/
https://tls13.xargs.org/#client-hello
https://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.203.pdf

While it did argue for X25519MLKEM512 (and X448MLKEM1024) I did not understand at the time that I would have wanted X25519MLKEM512 for middlebox traversal. Then I would have argued harder for X25519MLKEM512.

The current situation is that OpenSSL 3.5 LTS has shipped with X25519MLKEM768, ML-KEM-512, ML-KEM-768, and ML-KEM-1024 and even if TLS WG standardise X25519MLKEM512 now, it will take several more years until it would be added to a OpenSSL LTS, which a lot of infrastructure is based on. That would make it hard to meet 2030 deadlines for PQC migration but would meet 2035 deadlines. I can live with ML-KEM-512 for middle box traversal, but if TLS WG does not publish ML-KEM-512, I would suggest that X25519MLKEM512 is added to draft-ietf-tls-ecdhe-mlkem.

(Regarding misbehaving servers, if they don’t handle fragmented ClientHello they likely don’t support ML-KEM anyway and you need to retry with standalone X25519. Middleboxes and load-balancers is the big problem)

Cheers,
John

On 2025-11-27, 20:43, "Stephen Farrell" <stephen.farrell@cs.tcd.ie<mailto:stephen.farrell@cs.tcd.ie>> 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?

Thanks,
S.


_______________________________________________
TLS mailing list -- tls@ietf.org<mailto:tls@ietf.org>
To unsubscribe send an email to tls-leave@ietf.org<mailto:tls-leave@ietf.org>
_______________________________________________
TLS mailing list -- tls@ietf.org<mailto:tls@ietf.org>
To unsubscribe send an email to tls-leave@ietf.org<mailto:tls-leave@ietf.org>

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