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

Eric Rescorla <ekr@rtfm.com> Mon, 20 October 2025 12:12 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 B237A77CC3D4 for <tls@mail2.ietf.org>; Mon, 20 Oct 2025 05:12:25 -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 gasPA9J6EnyO for <tls@mail2.ietf.org>; Mon, 20 Oct 2025 05:12:25 -0700 (PDT)
Received: from mail-yx1-xb12d.google.com (mail-yx1-xb12d.google.com [IPv6:2607:f8b0:4864:20::b12d]) (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 0025F77CC3BF for <tls@ietf.org>; Mon, 20 Oct 2025 05:12:24 -0700 (PDT)
Received: by mail-yx1-xb12d.google.com with SMTP id 956f58d0204a3-63e1b52b452so3206605d50.1 for <tls@ietf.org>; Mon, 20 Oct 2025 05:12:24 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20230601.gappssmtp.com; s=20230601; t=1760962344; x=1761567144; 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=ni9wLDHUatkbB47VdxPmmk2huRfk2YTy5hTTBPecnIw=; b=RXZE64EKDvFoActVbNEr5gr/sPO+qpGT/A1pzR45FKM6Q2sxm9gqLcPNg6mQ7BRQUg H1h/ObyEEL2JlzrQFculN0Zr5w6FO4nvjqYQdnl5bUVfaW15zkemsn7fVTx/orWUSxaH 2NRPG+DhqTmiQ8Zw3W0IlXbs/BgvkwoqJXdUett9yeZqQcT3MpumeJhL8jILbSi0LJBG QMHSaT5H3TwOYZwE3KWqghXJnNZhW8zgUzQk+LHbuI/RJ/K12f4T6aFlZvkbohC6i4ak nNHG3De3SjDQhb0433VJUHFpz/SP6Rbur5Cet8NgurBSk9ly9gjy4CH0MRUBUk4DQeaU +v2g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1760962344; x=1761567144; 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=ni9wLDHUatkbB47VdxPmmk2huRfk2YTy5hTTBPecnIw=; b=SyUMT0kPzpqUcJBz0V8snYY2EWvlKPMIu+wd/oX69bTZSEKTHMA7ADixjsfHhNyrsQ Qjb+MuZUCTG1dzWrH5xsbkgjY4dNjBR60xXNlZ2GHio1O2TZh446a4MMJgYxJ7Ix5SFX gV0UC+awEH7AQAYl+vELTuyPfYxFvYNFS6LRiSOTOI7g5C9J73O2RfNLn7rYtTzWpbEh /cCGCW8UD54wI6UH+7qxzt3U2TrF83BliklUpEOCGRuLmNPgkH04ZfRDBSmNh2aKHLIq 1ElZNtkYr7llQaQoKtkrBpvb6XRp4F6Ec+WTkkbwYUlJB510ZCjgLCIJxfuFTs8EDCrX dzBA==
X-Forwarded-Encrypted: i=1; AJvYcCXgoRZK8H0jk8EOOSGmicwxjMM0Flpc0hpGm8reQb2tA/EUIxQGeMz/j6985ZTT8WpY0uk=@ietf.org
X-Gm-Message-State: AOJu0YzwJRYrAlv//JcVuhtM50u4bDNiasxI96tOWZyPfvbarF3qVK+L s0kOq15qCowUhXwKD1lv/fQIY678ij6b76gTk4mH3bh6hdGb6aLyzRmFdAeRwJH9o58l304Ox6b H/wSDKcNp4/Bc3jUnv3M3MSsl1CNSBQg0yh0BP4ZIKg==
X-Gm-Gg: ASbGnctVJmR4Up6ZnpHX8NFrEFHg67HCHSVvNrbO6hdqKtdr86vxmFgfsS0NA/NQkX4 vgD9jfck+PqlhKf+D/48TkSlAid6B4373ByIlLynjn7xyl6Heqg2iAPto8pXJb1nVob5NZrsVki OQ/NL3PqciMZJc7dO9IxAsttPRD87sqifS7Cuy6byE4xBsNRanFho8lswARAO9dzIIPZFAAWATe GCosZGoFp+UPPKGBSRgy2+v+MCEDT+rHIxwQKX21/bgLIMWCMSRH76xC4+XP2GrhNJyAJtG/Iiv FvBUUV6eKUBXQldKCbHloiM799LUOcl+3qhUBkwUS93GEbbqUZelYvhqmB7vkrj35pJKM8e4obi fjq1M6D9/Cg==
X-Google-Smtp-Source: AGHT+IE21/POG/9JlFyRq4s5dVhz7FWNL8uzSWTNxq8yvpOpGU2FuNlwKS6t9Z5aM/4foli4iZL/KWPzCO6m6e65/3M=
X-Received: by 2002:a05:690e:134e:b0:63e:3296:8886 with SMTP id 956f58d0204a3-63e3297a274mr3513047d50.42.1760962344386; Mon, 20 Oct 2025 05:12:24 -0700 (PDT)
MIME-Version: 1.0
References: <GVXPR07MB96783CA29F52103DA1B7A58689F5A@GVXPR07MB9678.eurprd07.prod.outlook.com> <3a21e24b-6f87-4f25-8f2c-e1f7d59ab856@amongbytes.com> <GVXPR07MB96788518E72F2863F72EA36D89F5A@GVXPR07MB9678.eurprd07.prod.outlook.com>
In-Reply-To: <GVXPR07MB96788518E72F2863F72EA36D89F5A@GVXPR07MB9678.eurprd07.prod.outlook.com>
From: Eric Rescorla <ekr@rtfm.com>
Date: Mon, 20 Oct 2025 05:11:48 -0700
X-Gm-Features: AS18NWDD_AdnPjGD_mHUwcWWpg9hBgDz23bsf5BPDgxPGjAO4QdO-KXNGp8uocU
Message-ID: <CABcZeBOnCiyw1E3Zi_dJ14ABFKv9UN8x+21S3KJC0SjVKT=ChA@mail.gmail.com>
To: John Mattsson <john.mattsson=40ericsson.com@dmarc.ietf.org>
Content-Type: multipart/alternative; boundary="000000000000001559064195ffb2"
Message-ID-Hash: EEXUWLNIHLUTIINTVMBZ4YDJAGSLUJMQ
X-Message-ID-Hash: EEXUWLNIHLUTIINTVMBZ4YDJAGSLUJMQ
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: Kris Kwiatkowski <kris=40amongbytes.com@dmarc.ietf.org>, "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/aaIWdP-BKCvKDYC6gFOO4797lwg>
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>

What's the difference between an ephemeral key that's reused and a static
key?


-Ekr


On Mon, Oct 20, 2025 at 5:10 AM John Mattsson <john.mattsson=
40ericsson.com@dmarc.ietf.org> wrote:

> SP 800-227 is already required by FIPS 203 for the use of ML-KEM in
> applications. Referencing SP 800-227 directly, rather than just indirectly
> through FIPS 203, is not a technical change.
>
>
>
> SP 800-227 disallows the use of an ephemeral key in more than one
> key-establishment execution. It permits the reuse of static keys, as well
> as the reuse of ephemeral keys across multiple key shares, provided that
> only one of those shares is used for key establishment.
>
> John
>
>
>
> *From: *Kris Kwiatkowski <kris=40amongbytes.com@dmarc.ietf.org>
> *Date: *Monday, 20 October 2025 at 13:29
> *To: *tls@ietf.org <tls@ietf.org>
> *Subject: *[TLS] Re: Working Group Last Call for Post-quantum Hybrid
> ECDHE-MLKEM Key Agreement for TLSv1.3
>
> Just to be crystal clear - that would be a way to disallow a key reuse in
> TLS v1.3 when using MLKEM (as per RS6 in Section 1.3). Correct?
>
> On 20/10/2025 12:05, John Mattsson wrote:
>
> Hi,
>
> I am cornered with the current PR #53 suggesting that SP 800-227 “provides
> general guidance”. This is not a correct description.
>
>
>
> As stated in FIPS 203, SP 800-227 provides requirements for the use of
> ML-KEM in applications. TLS 1.3 is such an application.
>
> Unless the working group wants to discuss each requirement in detail, I
> would suggest just adding:
>
> ”As stated in FIPS 203 {{FIPS203}}, SP 800-227 {{NIST-SP-800-227}}
> provides requirements for the use of ML-KEM in applications.”
>
>
> In general, I think it is very important that IETF follows NIST
> requirements when using a NIST algorithms like ML-KEM.
>
> Cheers,
> John
>
>
> https://github.com/tlswg/tls-ecdhe-mlkem/pull/53
>
> https://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.203.pdf
>
>
>
> _______________________________________________
>
> TLS mailing list -- tls@ietf.org
>
> To unsubscribe send an email to tls-leave@ietf.org
>
> _______________________________________________
> TLS mailing list -- tls@ietf.org
> To unsubscribe send an email to tls-leave@ietf.org
>