[TLS] Re: [EXT] Re: WG Adoption Call for ML-KEM Post-Quantum Key Agreement for TLS 1.3

Nico Williams <nico@cryptonector.com> Thu, 17 April 2025 22:23 UTC

Return-Path: <nico@cryptonector.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 39B221DD9EB3 for <tls@mail2.ietf.org>; Thu, 17 Apr 2025 15:23:52 -0700 (PDT)
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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H5=0.001, RCVD_IN_MSPIKE_WL=0.001, RCVD_IN_VALIDITY_RPBL_BLOCKED=0.001, RCVD_IN_VALIDITY_SAFE_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: mail2.ietf.org (amavisd-new); dkim=pass (2048-bit key) header.d=cryptonector.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 IhUSvUlR9iwe for <tls@mail2.ietf.org>; Thu, 17 Apr 2025 15:23:50 -0700 (PDT)
Received: from caracal.birch.relay.mailchannels.net (caracal.birch.relay.mailchannels.net [23.83.209.30]) (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 089811DD9EA7 for <tls@ietf.org>; Thu, 17 Apr 2025 15:23:49 -0700 (PDT)
X-Sender-Id: dreamhost|x-authsender|nico@cryptonector.com
Received: from relay.mailchannels.net (localhost [127.0.0.1]) by relay.mailchannels.net (Postfix) with ESMTP id 22E731A240A; Thu, 17 Apr 2025 22:23:49 +0000 (UTC)
Received: from pdx1-sub0-mail-a313.dreamhost.com (100-109-60-185.trex-nlb.outbound.svc.cluster.local [100.109.60.185]) (Authenticated sender: dreamhost) by relay.mailchannels.net (Postfix) with ESMTPA id BD39D1A2B94; Thu, 17 Apr 2025 22:23:48 +0000 (UTC)
ARC-Seal: i=1; s=arc-2022; d=mailchannels.net; t=1744928628; a=rsa-sha256; cv=none; b=z0BPfq2GP19NnGiVi06o/qoozqkrmweOo5ZwblQeGLwKwgha8CO46Q1JIot8dGqJ6Oxdeb Jw8aotzp7LGoQOHsdUIQKisRrjfDUDtUGuxcMhmX9TI3BD4bFYP1WSqL1UXBLfFiXAECJN 0BwuuNs0gHaOAe8+mBvbXINW75EsdDmzLNK64SkiFS4bv+H3I7uxeQJa1UlHSZM9UtFQ1k FD6jsRwop3hX4GXe25HzGS6BmRPKxlFO+Yt+oOwMc2TuJgcPx5piaPsCYGbhAf+3KJlbG0 YymdTnwkFkwpXIf8xvXmlrYTq9Q4cRehaKojNrBhqTePQY3dCIttztg4mWaP/Q==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=mailchannels.net; s=arc-2022; t=1744928628; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=UpeyotOJEZH9u3Am/2nB8Ax6qi9PiEm134M2ZZYDpGo=; b=jaEsV15VW4hLowKCgO2fGkSO5PXRS/5PDkmI5Fe0ccVLNu99I7+xILlBIBQ2hMTprMrqbB qq3wHZKFE2P/skduK9C6t9LAlGcWc4PDlin4O15MC33m8m8Hf8350IbudlF1QnweQ8/DNq RmKW4zY0eEaU+bXmx1jFzo37vODEX7aW4UHXzP+2RTXcblH3Tf83JJadGfWcREh8S2mp8/ QucECzFC/jh8jThYRuNCqbviC2T2ygzjxxFt5r5dm8EXyIUflTf5Lfr2ZmvtGvuKFfTZUQ Afu4k+m5vFfez/e1pZJZat9k6Evb1BLLp4is5O2I5P9/tPz9iNkBWFrvFeyWiQ==
ARC-Authentication-Results: i=1; rspamd-7bd9ff6c58-dhqhn; auth=pass smtp.auth=dreamhost smtp.mailfrom=nico@cryptonector.com
X-Sender-Id: dreamhost|x-authsender|nico@cryptonector.com
X-MC-Relay: Neutral
X-MailChannels-SenderId: dreamhost|x-authsender|nico@cryptonector.com
X-MailChannels-Auth-Id: dreamhost
X-Thoughtful-Suffer: 2ead6dc7492205f6_1744928629003_3872945772
X-MC-Loop-Signature: 1744928629003:1104635104
X-MC-Ingress-Time: 1744928629002
Received: from pdx1-sub0-mail-a313.dreamhost.com (pop.dreamhost.com [64.90.62.162]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384) by 100.109.60.185 (trex/7.0.3); Thu, 17 Apr 2025 22:23:49 +0000
Received: from ubby (syn-075-081-095-064.res.spectrum.com [75.81.95.64]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by pdx1-sub0-mail-a313.dreamhost.com (Postfix) with ESMTPSA id 4Zdsqm1C9gz55; Thu, 17 Apr 2025 15:23:48 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cryptonector.com; s=dreamhost; t=1744928628; bh=UpeyotOJEZH9u3Am/2nB8Ax6qi9PiEm134M2ZZYDpGo=; h=Date:From:To:Cc:Subject:Content-Type:Content-Transfer-Encoding; b=D7OH6f44QoC1GT2wfAskgUALl0GIyzLZWHB/wKsjB61oZzR/Tsjy2i1ZIQE1mEm/Q AEQ6S2atsTIF0Ird+AzX0MOtr4CE2fBqxap2fNXaUB1EUETMMPtDa1fs0Ipuko3PAk 6kRy1MqR/FX95j2LwVre0vE91jAumbc39wKlpJ0U9fpHp9iFMwxhlODAPF8kl3QRk8 rRl85e0oN/MdS9LaCrZ7Kj/ZCX0KECUOJgK/axQTciRb8lUnp4rZ18YaOAT9Pwp1D2 9qC5Qui63S3XWm4Xap0SNtR0+Y4QqP0V3SLZVSGH0bGGz2XG8P0tDV+soFI0VWnhD1 F1DHfQvEy4pJg==
Date: Thu, 17 Apr 2025 17:23:45 -0500
From: Nico Williams <nico@cryptonector.com>
To: Benjamin Kaduk <bkaduk=40akamai.com@dmarc.ietf.org>
Message-ID: <aAF/cQ4Yftrulr9B@ubby>
References: <5dd1e81a-c37a-ceff-b89e-b4335fca07b6@nohats.ca> <56e646395f67e27ff11a092d5989c1c85eba2563.camel@aisec.fraunhofer.de> <CAOp4FwSJpvn6f=3utd4yBE=ftkXQ4h38FT3VQ1XOhrubqgu0ng@mail.gmail.com> <BN0P110MB1419E8DB9B38B33F41A6234590BCA@BN0P110MB1419.NAMP110.PROD.OUTLOOK.COM> <IA1PR17MB64212A6A5AC34467EB83F2A5CDBC2@IA1PR17MB6421.namprd17.prod.outlook.com> <BN0P110MB141930A9829053013376FF7C90BCA@BN0P110MB1419.NAMP110.PROD.OUTLOOK.COM> <aAF0FxjVgb7EGdGR@akamai.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <aAF0FxjVgb7EGdGR@akamai.com>
Message-ID-Hash: QSXQSAQ7LOIQDVCHCQAIFYAZ5FKGWHKG
X-Message-ID-Hash: QSXQSAQ7LOIQDVCHCQAIFYAZ5FKGWHKG
X-MailFrom: nico@cryptonector.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: [EXT] Re: WG Adoption Call for ML-KEM Post-Quantum Key Agreement for TLS 1.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/G7fo-EBCSAjto1nRRDzUIjITcAc>
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, Apr 17, 2025 at 02:35:19PM -0700, Benjamin Kaduk wrote:
> [trimming heavily since the text/plain component is made of lies and I don't
> want to misattribute nested quotes]

Yeah, if you're using a text-based MUA HTML gets painful.

> On Thu, Apr 17, 2025 at 09:17:29PM +0000, Blumenthal, Uri - 0553 - MITLL wrote:
> > 
> >    There’s maintenance of the code for both parts of the KEM and ensuring
> >    they’re properly integrated, maintenance of parallel PKI structures, need
> >    to allocate the costs for two moves [1] instead of one which already makes
> >    some users argue (which can be a royal pain in a large deployment), likely
> >    many other things I’m too lazy to concentrate on now (besides, there’s
> >    that feeling that I don’t need to convince “my” clientele at all, and
> >    there’s little chance to convince this audience anyway, which dampens the
> >    eagerness to strive).
> 
> Thanks for writing up this list.
> 
> Just to check my understanding: the PKI only comes into play for signatures,
> and there is no PKI needed for ephemeral key exchange as is used in TLS 1.3?

[Not-Uri] Correct.

> (For the specific case of ephemeral key exchange in TLS 1.3, it seems that the
> "move" is just a software update, albeit one that needs heavy testing and in
> your enviroment qualification.)

ISTM that a hybrid should add very little extra code compared to the ECC
and ML code.  I'm unconcerned with the maintenance cost of that.
There's not "two moves".  You just keep deploying TLS stack updates and
eventually when we're all happy with pure PQ we just stop using ECC and
the hybrids.  There's no PKI work needed for key exchange.

Now for hybrid signature schemes for PKI... it's not too dissimilar.
The biggest hurdle when it comes to PKI is that the installed based of
relying parties has to implement the new signature schemes before you
can really use them, though of course protocols can always negotiate
support and the supplicant can pick from multiple certificates to
present to the rp.  Basically you have a longer tail to deprecate older
signature algorithms when it comes to PKI, but that's not fatal.  And
yes, you'd need "parallel PKI structures", but that's mainly a problem
for the CAs and the CA/Browser forum, not for everyone else, not for the
relying parties, and it's not a big problem.

Nico
--