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

Watson Ladd <watsonbladd@gmail.com> Fri, 18 April 2025 21:59 UTC

Return-Path: <watsonbladd@gmail.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 B8ADB1E514C6 for <tls@mail2.ietf.org>; Fri, 18 Apr 2025 14:59:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at ietf.org
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Level:
X-Spam-Status: No, score=-2.099 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, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: mail2.ietf.org (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 dW7giLQkMxkC for <tls@mail2.ietf.org>; Fri, 18 Apr 2025 14:59:15 -0700 (PDT)
Received: from mail-wr1-x42f.google.com (mail-wr1-x42f.google.com [IPv6:2a00:1450:4864:20::42f]) (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 4A8151E514BE for <tls@ietf.org>; Fri, 18 Apr 2025 14:59:15 -0700 (PDT)
Received: by mail-wr1-x42f.google.com with SMTP id ffacd0b85a97d-3913958ebf2so2093461f8f.3 for <tls@ietf.org>; Fri, 18 Apr 2025 14:59:15 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1745013554; x=1745618354; darn=ietf.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=itrF/zj6ktiSptngegLpydfwS3Ppw9sX1EvQ4kmzQ2A=; b=jpJZoj5MOo3n8RWsQ7r9oFOPkj01G6tpfYJqv95ALnFgqqyxNUdJpDVqcxikUq/jvi 2M5Bps4v+O35aDiMWOwDZf0Qdr6IB/XYkliIhiyeq0THni3/VTlSTmhN2mhTV9xvw0D+ L8ifRFSX2wqEBCwoX4LpITU9/a5XIHrqWmTrSUgHA4T+DO2vJLIK3MBx5fCgoP7bIK6S hgVfa6UG/93G7IiJPLdtCwFUU8WMRb05tKFXCSnV7IOlfC0S+L7PdTqrEO+gcH9GfLxW 9k9b+dfwNkptbx4tD4i0TpNlBc5pgO0laVTyawLqR1Ybi2tt48WB+8rF76YIHOubSuqk u7Fw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1745013554; x=1745618354; h=content-transfer-encoding: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=itrF/zj6ktiSptngegLpydfwS3Ppw9sX1EvQ4kmzQ2A=; b=TXzkQfbXf9+WEmMoPkm9y61z2gsNKwmfMzxys8fyFivSmxYZKiTTimpBKZaGjfYDR5 6S+vpJ5eTlIn+s+Rv5x6V6T+aFmMrfiGJQn42M6NtPpkEi4a/4StWm5OB2PBdb2eaZbw Vd2ZDVbPPH0jwEcwaXqji9aAdRS2Fl1twa+cWlPecE5N/rwfZkABFzCFDoLSs3VkeR1S YdvqjtNqthim0nx4qsfZ3aDBtdLFNgdTGD4Q0RGuawmqLmH1OWkRvzaWl+Uc5HWEC9Zi RdkIROEztJaodtnUXgu+KkTZzBVtL8mluFFPDJewUHvUZL8kmxGmWcvzyc0BweTQCBLc i63A==
X-Forwarded-Encrypted: i=1; AJvYcCXBQAgn2X9HCofkUTXF4WaNsRrOrpG/M3Hjw+V/nmCX5oHSAFtEESbmsCcn8q4jqhRisCI=@ietf.org
X-Gm-Message-State: AOJu0YzZNYYez/6lStkPwRKKP2B3zVt9kJQ7XFgDMLi6/XBxxmXBYl3U qGDAug1hilfxwxEA9rGEWREqd/Pu13hf/igvQzI0q0QsFpCWnEsgtOUMGKXIAOsTdSlc1gehTnj UUWuUMkYuS01EwiF5Y8AQFbu33JU=
X-Gm-Gg: ASbGncvCyiCO7V6L9pc1/gDK7Re/RkD4e9kCAE4ksfVZuoRYggQHn2zbaCnbOA+pT5T Q+WTN8mq4gQo7CUAW5d9VQeXZmewsbicagHYEgAWgsLlRkYNJR/39veySDqCmOVhijG4OcNzWkp TgdektgzvwiVJlesHeZc5LvtJ1JPXBktocPwh4MgJJ20UlOx45Ziw=
X-Google-Smtp-Source: AGHT+IGj8VQhd1+pznjj4UvoMGt7xSXouX/wksp1YS0NNmOrqaxeW0Oyz8DuuokQiIjMcqeLWgj5PJhIIhj4fJ+0FAk=
X-Received: by 2002:a05:6000:40ce:b0:39e:e588:672f with SMTP id ffacd0b85a97d-39efbaf2557mr3387440f8f.55.1745013554257; Fri, 18 Apr 2025 14:59:14 -0700 (PDT)
MIME-Version: 1.0
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> <BN0P110MB1419804C8272218B2B229D0F90BFA@BN0P110MB1419.NAMP110.PROD.OUTLOOK.COM>
In-Reply-To: <BN0P110MB1419804C8272218B2B229D0F90BFA@BN0P110MB1419.NAMP110.PROD.OUTLOOK.COM>
From: Watson Ladd <watsonbladd@gmail.com>
Date: Fri, 18 Apr 2025 17:59:02 -0400
X-Gm-Features: ATxdqUHv_mUhwZBzWApB5Aeusg_Gyncp6IfGEK2M8mWqfw4LdJ-zAC8faCkUQOs
Message-ID: <CACsn0cn5XuWRF=qVB45oDdYv27CtiRwJ7C4ZD1_B=NPK6Nzt1A@mail.gmail.com>
To: "Blumenthal, Uri - 0553 - MITLL" <uri@ll.mit.edu>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Message-ID-Hash: 7M3GIPE4ZLE4632YSKBSRNCDVMQUUYIV
X-Message-ID-Hash: 7M3GIPE4ZLE4632YSKBSRNCDVMQUUYIV
X-MailFrom: watsonbladd@gmail.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/lE7xK6Z427a99BwkZyzgq1JG7uA>
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 Fri, Apr 18, 2025 at 5:29 PM Blumenthal, Uri - 0553 - MITLL
<uri@ll.mit.edu> 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.
>
>
>
> Sure.
>
>
> 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?
>
>
>
> An interesting point here. For the current approach – indeed, ephemeral KEX does not need PKI.
>
> However, consider AuthKEM proposal, and KEMTLS – while ephemeral keys certainly won’t depend on PKI, the static ones will.

But you can't have the AuthKEM keys going all the way up the PKI, but
need a signing key. And at that point you might pick the right
signature for the job at each level: big public key ok for root keys
if it makes signatures smol. Intermediates have to be fairly balanced,
but if you can elide, tradeoff similar. And signatures on ends need
pretty quick verification.

>
>
>
> And, frankly, my work is standardizing a similar-to-above approach for other protocols (which is not that novel – e.g., think MQV/HMQV).
>
>
>
> That’s the approach we’re following. Though we plan to submit only to other WGs, and not TLS – because, in our opinion, KEMTLS addresses the PQ needs quite fine, and ours would just duplicate that proposal.
>
>
> (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.)
>
>
>
> Essentially, yes – except that “just” in reality (for us, at least) is a lot more involved than that.
>
>
>
> _______________________________________________
> TLS mailing list -- tls@ietf.org
> To unsubscribe send an email to tls-leave@ietf.org



-- 
Astra mortemque praestare gradatim