[TLS] Re: Working Group Last Call for Post-quantum Hybrid ECDHE-MLKEM Key Agreement for TLSv1.3

Eric Rescorla <ekr@rtfm.com> Tue, 07 October 2025 16:40 UTC

Return-Path: <ekr@rtfm.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 D9AA16EC40EB for <tls@mail2.ietf.org>; Tue, 7 Oct 2025 09:40:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at ietf.org
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Level:
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=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=rtfm-com.20230601.gappssmtp.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 LZverHZcUHyl for <tls@mail2.ietf.org>; Tue, 7 Oct 2025 09:40:44 -0700 (PDT)
Received: from mail-yw1-x1133.google.com (mail-yw1-x1133.google.com [IPv6:2607:f8b0:4864:20::1133]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature ECDSA (P-256) server-digest SHA256) (No client certificate requested) by mail2.ietf.org (Postfix) with ESMTPS id BE1286EC403E for <tls@ietf.org>; Tue, 7 Oct 2025 09:40:29 -0700 (PDT)
Received: by mail-yw1-x1133.google.com with SMTP id 00721157ae682-74435335177so1394207b3.0 for <tls@ietf.org>; Tue, 07 Oct 2025 09:40:29 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20230601.gappssmtp.com; s=20230601; t=1759855229; x=1760460029; darn=ietf.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=mUn6p6pNFekNkLyefmoT822FWgaGEX1HHobnazCwcN8=; b=bgGxzoFi3c3L/P+xj+nemE8zC4LIIvj39m3tGpVYKrcsKu/Y5yzkLwglfMYnRVnyK0 B1MBP28q/671cYP8qvjK89yERJrLnDq67OcVVuXOr2xzPahUvn9CEnY39UzDfGFtNpJk 4AjrLXIvCbuEUHnSMqV7w1uTqU36sLZeXA532bLzaVr77hwHmbkfFd33fz2Rz0yy+MA5 XkKl5dbKrIvjYMNzvwmgg6jfBw6j1ht0qt+aZHh4RteBlV9O4WrPxbGsbjb3bMbiql/5 ipu/92J5DIuv9P+kYmmB3Y2JBlxKllMrRKjWOrh8nNMg/HtsRXflU+tHhNl69ga8UJUe F1fA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1759855229; x=1760460029; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=mUn6p6pNFekNkLyefmoT822FWgaGEX1HHobnazCwcN8=; b=SsKDmuxJwLYQAhEId+8jLNFdBrcLJsZwzUdAnWI6a3whYDoEyJ0T4VvbSuyWoNPMf+ VCZvBWu4g2Aq4gcm1N2xrhnxFggp2EBG3IsAQcZ3izjSQPo4Aavuj5lPdzbjYEky2UhW +K7YidnujADeUFi/2O8qMDVDOQ5f5K1708/blrMr/SGpKittV9P86iyeDWjUDGibjaWR WNG4h/Bkt4z2LALrNDV+Rfl+7nWaJqvM2Ec+uk2jB3C9bh/nbs36mbsPxlkkE9gaM+aN vlU/5TDvneRmdoXZ/jAerQt0LyPDI0y9WYnvJPN2eKxQo5IRQatbVVpT+bL/UN7RaSNf hYiw==
X-Forwarded-Encrypted: i=1; AJvYcCVwrMMd1o7glKKO+wFZv9CNPBtUImoouTI0KTRg/wnoDAiv6tP1JfM4Z6PfckM4xGCpyYI=@ietf.org
X-Gm-Message-State: AOJu0YzYY+nSZSoJQ3Bk9UK8fPbI3WrFMcrDWmdyQv0jn+Uj1IY1tJnD FRBoc0Xw51elmBDwDON63arfNKAQ+7OGTmv8gfFoalfAmjMfYoDVOrg8BlMIlt4e97pvlTtX5YI Wfherpfs7KE928NbG2rIz7276UO+Tf90HBBCZMyxsXw==
X-Gm-Gg: ASbGncsU+hbWhIdGg/MMEpR7DNwyNtZu/cpDeoRUOckT4nl1UtvD+/FJ/dlLBueLlGH f2DaNKzr0rVWkXjtyfjr5ZkUs1PExTi1D8TfARGfedNWf3zx/DyD74RLSYGlj/KI9F40/IjAYTy KawYVoMy+/dB9CvgmO8mEpiLlKahmrMMiFgMSLe69KcjkuXIdMPPv5VEA7YRxW/oWBSGYbtmOCc 1bpw862KyFF4mptuow82jiiQye1cJkWEWK2ygIYjpNBiVmZIwP578Tili2euUg9rC2X7F3XWlCu 27pN+cEreIjZWq0hyXT7c5WD2ERaApGizCpHN4UbE24=
X-Google-Smtp-Source: AGHT+IHLqS6M8YZc5mIKb3ob7MlpuIUL/UYsBGJxaES3kMIQdaW4oKtnVykyjZV6ImpmPFHlUXOkNCMAqBZpcl/0n+s=
X-Received: by 2002:a53:c383:0:b0:633:a6fa:386b with SMTP id 956f58d0204a3-63cbe09ad4cmr3199169d50.9.1759855229022; Tue, 07 Oct 2025 09:40:29 -0700 (PDT)
MIME-Version: 1.0
References: <CAOgPGoA+c8kXDizwsvFG5tLz9+Kxk0HqiN1skKp5jMvvpxeu0Q@mail.gmail.com> <CABcZeBO+3u=1=ueNscq+O74Qv=7PC5NedsGsugp=GZjVqtODoQ@mail.gmail.com> <1040fcc9-46e3-197e-1fa7-353c978486fb@nohats.ca>
In-Reply-To: <1040fcc9-46e3-197e-1fa7-353c978486fb@nohats.ca>
From: Eric Rescorla <ekr@rtfm.com>
Date: Tue, 07 Oct 2025 09:39:52 -0700
X-Gm-Features: AS18NWAfNEv6HLkwMkF_p-Rzeu3etS3yIcJys9RIlSSXmPf6hdDX3GICDBbd0RM
Message-ID: <CABcZeBMZ=0ByGpDzHsfq2m3wO9NhpEoFX+2k0_8NhTiAYekqBw@mail.gmail.com>
To: Paul Wouters <paul@nohats.ca>
Content-Type: multipart/alternative; boundary="000000000000c8489106409439ce"
Message-ID-Hash: DF6ZKAX6OTAOXN3XWDZZWAKU4QWKWPLS
X-Message-ID-Hash: DF6ZKAX6OTAOXN3XWDZZWAKU4QWKWPLS
X-MailFrom: ekr@rtfm.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: Working Group Last Call for Post-quantum Hybrid ECDHE-MLKEM Key Agreement for TLSv1.3
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/OLNiYYvZj0Tm3zZhxcG7mXLwpRE>
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 Tue, Oct 7, 2025 at 9:18 AM Paul Wouters <paul@nohats.ca> wrote:

> On Tue, 7 Oct 2025, Eric Rescorla wrote:
>
> > Date: Tue, 7 Oct 2025 10:51:50
> > From: Eric Rescorla <ekr@rtfm.com>
> > Cc: "<tls@ietf.org>" <tls@ietf.org>
> > To: Joseph Salowey <joe@salowey.net>
> > Subject: [TLS] Re: Working Group Last Call for Post-quantum Hybrid
> ECDHE-MLKEM
> >      Key Agreement for TLSv1.3
> >
> > I have reviewed this document and I think it is ready to go with
> > one exception, namely the Recommended column.
> >
> > The RFC 8447 standard for "Recommended=Y" is:
> >
> >    Per this document, a "Recommended" column has been added to many of
> >    the TLS registries to indicate parameters that are generally
> >    recommended for implementations to support.
> >
> > I think there's a general expectation that we want people to
> > implement and deploy these algorithms, and I would expect
> > that the X25519 and P-256 versions to be widely deployed,
> > at least on the Web. Therefore, I think we should mark all of
> > these as Recommended=Y. I note that this would require
> > advancing this document as Proposed Standard. We should do
> > that as well.
>
> Eric,
>
> As has been previously found, the problem of discussing the RECOMMENDED
> Y for each draft separately, instead of periodically as a group, leads to
> relitigating these things over and over again.


That was true in the context of SSH, but it's not clear to me that it's
true in the context of TLS, where the semantics of "RECOMMENDED=Y"
are entirely different. For context, there are currently four such supported
groups for TLS: X25519, X448, P-256, and P-384. Is there a substantive
reason why the hybrids of these same groups with MLKEM ought not
to be RECOMMENDED=Y?


One new algorithm appears
> and people want to rediscuss the other algorithms in the updated context
> again. Would you really be opposed to letting the current drafts get
> published with N while starting a dedicated document setup similarly to
> how other WGs have do this, eg RFC 8247/8221/8624.
>

Yes, I'm opposed to it. I think it's wholly unnecessary, and would
have the odd state where the algorithm in wide use is not at
PS.

-Ekr