IETF Logo Mail Archive

[TLS] Re: Disallowing reuse of ephemeral keys

Bas Westerbaan <bas@cloudflare.com> Fri, 13 December 2024 10:00 UTC

Return-Path: <bas@cloudflare.com>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 76159C1840DE for <tls@ietfa.amsl.com>; Fri, 13 Dec 2024 02:00:50 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.093
X-Spam-Level:
X-Spam-Status: No, score=-2.093 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, T_KAM_HTML_FONT_INVALID=0.01, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=cloudflare.com
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GoyjvFeFe1NI for <tls@ietfa.amsl.com>; Fri, 13 Dec 2024 02:00:46 -0800 (PST)
Received: from mail-yb1-xb34.google.com (mail-yb1-xb34.google.com [IPv6:2607:f8b0:4864:20::b34]) (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 ietfa.amsl.com (Postfix) with ESMTPS id B50BAC1516E0 for <tls@ietf.org>; Fri, 13 Dec 2024 02:00:46 -0800 (PST)
Received: by mail-yb1-xb34.google.com with SMTP id 3f1490d57ef6-e398484b60bso1081025276.1 for <tls@ietf.org>; Fri, 13 Dec 2024 02:00:46 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cloudflare.com; s=google09082023; t=1734084046; x=1734688846; 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=pJ28fwyCeqE9Gy9VCAF6wU+4Zb5iSqelNK9CqHdeneM=; b=FnNMD32pFGqZ1X7C4k3rNp45kA8n8YIBFWO09nDIRySs2QY/BXT2RObvxF2CVDlnir 5DK7kAjKcdamO3K4pdDW4sNQ+GzeMEHRlnTGaTQ7ZvomK7hASdbmH8CeJtBlwwEW8JN7 x0x5gu8odjArDrJZZwIfbeT9JDVMfz9G4jVFWlDuPiSxgc1skX62rETmk9mTXZ/2CNvG WZlyR24X/af/9U5Uu1ECRS7MhCevU03r07CX7P9ZrmBg2TQrFcywR3Oqdhl2RvLr32X9 rC/uR+0iC+Y28SNri91vhgLit/HnU9LPCruSYVJPY53Xmmaw2mNKR5dGD7N0/CTcFtP9 1bNg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1734084046; x=1734688846; 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=pJ28fwyCeqE9Gy9VCAF6wU+4Zb5iSqelNK9CqHdeneM=; b=h4G/+RhnTzk66aZMJwJFEi3CdngpwCGIPCyf6H2hlduPDlsY6CkrUqJI7SWRqXgDhS lMm4u+Z06dLL5wiwacPExkz//WXCTgHp986FSo5kWdpJ6ZsqrceFcZZpYCiPl+zO3vWv lrMFFfO02wmSyQIg5lSq7+lcd1Chb4G/fW2bkmOR7D8o+W863y7KjVM0WVeuVYZh5DR1 ChkDOmgnW8S10YxZUvFeIMmgN7heG+MMhajqLjMBCdpxiiP2OM2KOc3P+6FdkXXn7cWJ 1TJCZWv3tZ0AK+fCYxn13NHyjpIahAuFZhO00YVlLVHMib5QOyvcy6MAcOvHH6Kv8cgJ bBPw==
X-Gm-Message-State: AOJu0Yz7jDZzXeaymgxcBXRdI8fE8rzfDL7XKn1jCZ7XaM75PYZxKaeY XYBt2C50CAppWb546tVoUN9qn5/YOchNeXQBamL3JRX7B3Ho+YvKlUf5zt+anOqCzjivtk/exv/ vAq5FOH2BzlXfKxmM/RPi6GtSSgyFuf0ToBgiOlqT0MAfhHfc4PTEAA==
X-Gm-Gg: ASbGnctg3gUsi+niGULEreBx+hr2p+85S6bZovw8iksgyU+5+kSAo6RB6XjHPbLBcne I6GFeGHMxJRRqqS4H8V9mvCpGQ2C7h6EeYPaFngI5/1Qvcpc/QlSQKw==
X-Google-Smtp-Source: AGHT+IGzVplLSWPmcT6xVdtD8NpiN7M93QZlAg5u1O/PJLc4mzMI54YdRArIcqyowvP12BRoEUVU01HiZIs+R0Z8EcM=
X-Received: by 2002:a05:6902:1b8e:b0:e38:c40b:a0d6 with SMTP id 3f1490d57ef6-e43491ff294mr1912574276.10.1734084045795; Fri, 13 Dec 2024 02:00:45 -0800 (PST)
MIME-Version: 1.0
References: <CAOgPGoCHnXZzzoAFT8GGmByr=7y1j5wM3ptPc4_JBF3FhtVNmQ@mail.gmail.com>
In-Reply-To: <CAOgPGoCHnXZzzoAFT8GGmByr=7y1j5wM3ptPc4_JBF3FhtVNmQ@mail.gmail.com>
From: Bas Westerbaan <bas@cloudflare.com>
Date: Fri, 13 Dec 2024 11:00:34 +0100
Message-ID: <CAMjbhoVrVqsAC_5oaQxm_XMsjeUO1e2EbJQLMzH5u+NAZW9POw@mail.gmail.com>
To: Joseph Salowey <joe@salowey.net>
Content-Type: multipart/alternative; boundary="0000000000008ffc9a062923e7d8"
Message-ID-Hash: IYYLAUZ3VJQGQXR6IF73ZPXOTWIQN6IN
X-Message-ID-Hash: IYYLAUZ3VJQGQXR6IF73ZPXOTWIQN6IN
X-MailFrom: bas@cloudflare.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: Disallowing reuse of ephemeral keys
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/UX1NFgTpf8RqwlYK4o5G2Cnlvx0>
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>

I prefer 2.

On Thu, Dec 12, 2024 at 6:37 PM Joseph Salowey <joe@salowey.net> wrote:

> Currently RFC 8446 (and RFC8446bis) do not forbid the reuse of ephemeral
> keys.  This was the consensus of the working group during the development
> of TLS 1.3.  There has been more recent discussion on the list to forbid
> reuse for ML-KEM/hybrid key exchange.  There are several possible options
> here:
>
>
>    1.
>
>    Keep things as they are (ie. say nothing, as was done in previous TLS
>    versions, to forbid the reuse of ephemeral keys) - this is the default
>    action if there is no consensus
>    2.
>
>    Disallow reuse for specific ciphersuites.  It doesn’t appear that
>    there is any real difference in this matter between MLKEM/hybrids and ECDH
>    here except that there are many more ECDH implementations (some of which
>    may reuse a keyshare)
>    3.
>
>    Update 8446 to disallow reuse of ephemeral keyshares in general.  This
>    could be done by revising RFC 8446bis or with a separate document that
>    updates RFC 8446/bis
>
>
> We would like to know if there are folks who think the reuse of keyshares
> is important for HTTP or non-HTTP use cases.
>
>
> Thanks,
>
>
> Joe, Deirdre and Sean
>
> _______________________________________________
> TLS mailing list -- tls@ietf.org
> To unsubscribe send an email to tls-leave@ietf.org
>

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