IETF Logo Mail Archive

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

Simon Josefsson <simon@josefsson.org> Mon, 20 October 2025 15:11 UTC

Return-Path: <simon@josefsson.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 A037F781CA71; Mon, 20 Oct 2025 08:11:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at ietf.org
X-Spam-Flag: NO
X-Spam-Score: -4.401
X-Spam-Level:
X-Spam-Status: No, score=-4.401 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, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: mail2.ietf.org (amavisd-new); dkim=neutral reason="invalid (unsupported algorithm ed25519-sha256)" header.d=josefsson.org header.b="jXPNnu6f"; dkim=pass (2736-bit key) header.d=josefsson.org header.b="e/HJhoGR"
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 Wc1n-GzbKk2x; Mon, 20 Oct 2025 08:11:09 -0700 (PDT)
Received: from uggla.sjd.se (uggla.sjd.se [IPv6:2001:9b1:8633::107]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature ECDSA (P-256) server-digest SHA256) (No client certificate requested) by mail2.ietf.org (Postfix) with ESMTPS id 9A53D781C607; Mon, 20 Oct 2025 08:10:55 -0700 (PDT)
DKIM-Signature: v=1; a=ed25519-sha256; q=dns/txt; c=relaxed/relaxed; d=josefsson.org; s=ed2303; h=Content-Type:MIME-Version:Message-ID:Date: References:In-Reply-To:Subject:Cc:To:From:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description; bh=xAR241+Ste6p+Ma6v6xjFWp7eOgg0fAZUueyNLR18oo=; t=1760973047; x=1762182647; b=jXPNnu6fp0Qu9G6DjFCt4MJo/9Cx/TejI5AsKxf8PdM9w46CS9pxV0/kw+D+7ef4PqVincoSJ08 EQFFKWM2fBA==;
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=josefsson.org; s=rsa2303; h=Content-Type:MIME-Version:Message-ID:Date: References:In-Reply-To:Subject:Cc:To:From:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description; bh=xAR241+Ste6p+Ma6v6xjFWp7eOgg0fAZUueyNLR18oo=; t=1760973047; x=1762182647; b=e/HJhoGR1yLcluMqguP1Cm9RbAbKZESdY11tbpdUICSFNbn1PSlBE4loT/SsOVLx0C8FPygmLeD b3zvT1tnPbxXn0r7jgHpWZUaZ1Iqk14g+L9M2dRHP5o9T2pbzOpVrQFF7Yp3kJCp8LZFxle9kBWfG Amy1oslVLzrvq2qZntGkikObl0MaHgD0ZPEQId7tUbS6vLIL7RiN+hpCzvChMf+NMoO4pVs8vrlxG lHAfHTJYW3Y5GNn2sxGBkTHhI3wnIzKDeJC9hXtGzXACGxYo/uwKvizQ1rYpDaidaqbAS6UPSP0zu 6ou+EGee3BdK07dRcMsHHap6TyquwvBXwUpjQ/AMX8LomC+6bvtrbzrkjhvxuvC1Ls/B206AVTu8J s4yhK+aGVp1mpidF6wsfF8oYN30CkeMkY7FhS59Rh7Az1j8JtQLBSc+lS2BQFRIGBYLZxYlhJ;
Received: from [2001:9b1:41ac:ff00:2766:347f:b6a9:a22a] (port=49070 helo=kaka) by uggla.sjd.se with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.95) (envelope-from <simon@josefsson.org>) id 1vArX3-003d1n-R3; Mon, 20 Oct 2025 15:10:45 +0000
From: Simon Josefsson <simon@josefsson.org>
To: Eric Rescorla <ekr@rtfm.com>
In-Reply-To: <CABcZeBOH289QVSZomDfE8dUK5oB7kM0i_66s3S260WOjyTp4kw@mail.gmail.com> (Eric Rescorla's message of "Mon, 20 Oct 2025 07:47:14 -0700")
References: <GVXPR07MB9678ADD1D3268BB055751EA989F5A@GVXPR07MB9678.eurprd07.prod.outlook.com> <CABcZeBOH289QVSZomDfE8dUK5oB7kM0i_66s3S260WOjyTp4kw@mail.gmail.com>
OpenPGP: id=B1D2BD1375BECB784CF4F8C4D73CF638C53C06BE; url=https://josefsson.org/key-20190320.txt
X-Hashcash: 1:23:251020:tls@ietf.org::y3+64D0kHhsC/yMD:b8gI
X-Hashcash: 1:23:251020:ekr@rtfm.com::h2Jr7a5ERuQy/UW2:jq5u
X-Hashcash: 1:23:251020:kris=40amongbytes.com@dmarc.ietf.org::BOXtSA3yeBdkFnRC:pC3P
X-Hashcash: 1:23:251020:john.mattsson=40ericsson.com@dmarc.ietf.org::XGfXw+rkUVCNIfFw:t7uZ
Date: Mon, 20 Oct 2025 17:10:01 +0200
Message-ID: <871pmxip86.fsf@josefsson.org>
User-Agent: Gnus/5.13 (Gnus v5.13)
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-="; micalg="pgp-sha256"; protocol="application/pgp-signature"
Message-ID-Hash: SIYNJM2DS4743XIRZQS4DGYKU7QULM3V
X-Message-ID-Hash: SIYNJM2DS4743XIRZQS4DGYKU7QULM3V
X-MailFrom: simon@josefsson.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
CC: John Mattsson <john.mattsson=40ericsson.com@dmarc.ietf.org>, 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/j2cxKM2YmL1LqUgSJUHeSASiM70>
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>

Eric Rescorla <ekr@rtfm.com> writes:

>> *EKR wrote:*>It's purely about whether we think it's reasonable to implement.
>>
>> This is the current meaning. RFC8447bis will change the meaning to:
>>
>> “This only means that the associated mechanism is fit for the
>> purpose for which it was defined.”
>
> Right. Is it not the opinion of the TLS WG that P256/P-384 + MLKEM are fit
> for that purpose?

RFC8447bis requires IETF-consensus.  I don't think that question has
been asked IETF-wide at all so far, has it?  Has there been any
consensus call in the TLS WG on that question even?  So we don't really
know.

> If not, on what basis, given that we require you to implement P-256 alone?

I don't think this comparison with historic MTI of P-256 alone is
relevant for deciding about P256+MLDSA today.

It is reasonable that we required you to implement something a couple of
years ago that we wouldn't require you to implement today, but we
haven't gotten around to publishing an updated document.

Compare the migration away from MD4, MD5, DSA, DES, RC4.  The tendency
to move beyond those algorithms happened long time before we got around
to drop them from recommended/MTI status.

By that line of reasoning, it would make sense to standardize and make
MTI the brainpoolP256 curve too.  I don't think that is reasonable
today, so I think the analogy is invalid as an argument.

/Simon

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