[TLS] Disallowing reuse of ephemeral keys

Joseph Salowey <joe@salowey.net> Thu, 12 December 2024 17:36 UTC

Return-Path: <joe@salowey.net>
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 6A93FC14F714 for <tls@ietfa.amsl.com>; Thu, 12 Dec 2024 09:36:04 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
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_BLOCKED=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, T_SCC_BODY_TEXT_LINE=-0.01] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=salowey-net.20230601.gappssmtp.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 vA3nP_Hiuv_r for <tls@ietfa.amsl.com>; Thu, 12 Dec 2024 09:36:03 -0800 (PST)
Received: from mail-lj1-x232.google.com (mail-lj1-x232.google.com [IPv6:2a00:1450:4864:20::232]) (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 08C2DC1D4A73 for <tls@ietf.org>; Thu, 12 Dec 2024 09:36:02 -0800 (PST)
Received: by mail-lj1-x232.google.com with SMTP id 38308e7fff4ca-2ffd6b7d77aso9133741fa.0 for <tls@ietf.org>; Thu, 12 Dec 2024 09:36:02 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=salowey-net.20230601.gappssmtp.com; s=20230601; t=1734024960; x=1734629760; darn=ietf.org; h=to:subject:message-id:date:from:mime-version:from:to:cc:subject :date:message-id:reply-to; bh=AoSBaTPekJld+mEftE036rx1Y3lm5lyFjAQ6N2ehaEw=; b=CWDTvO4Z9yrIx68aPYEOlHdTAqwFc/ESdhXmvdtdr+TQoaPz20hizT3+abEvJOxagg d/Ay2og6ewwoSeyHWJTdEBihpWvqwEXr8zoqyg5OEjiNAeDiRYck65eI5fT9F74eNxDZ tI75bBzwfUgRjX9OKUePhstDjCRri50QPhj3WzabzMaV7XdvQnjnsXCyS4FRga4qoSwe Sy+STpR9uRSZeUtFH79evDH01kbMM9smGUBFydSuuFGmRUixVsksW+MS4ktbTGft2UZA iof2DS32/v9S6Darr/YcHqQu58VtFaXn04ljfTYFc/mDqBTwVFxGWeCgziGrJXuILuN8 HLQQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1734024960; x=1734629760; h=to:subject:message-id:date:from:mime-version:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=AoSBaTPekJld+mEftE036rx1Y3lm5lyFjAQ6N2ehaEw=; b=LZ12YjIQ7pqLkRqOpkVAwF00CFUKxusr/QGtARcUXREp4lwaDJikIaHt6mKJ35sKBd mbE+QMAZ8VhVTJaPnboW8wxZtPbKYNLzJDXmrFY85kuJVBQ66Gi3i7oEG7i5dzVCblfl R2aMgbpvhpCJeg7B91e0Ta6HQePAw89UqtDAGldFHvB5B21DzyNlk8O+zcCDF9UCZ+Hl erzxPgUCHXSv886IFCi0spl0nEBvK/qrMMRRnPgfkoJWx0AH0N0EcUcgmozCZnVcX5By tOlmntocPMLEWDGtEsZhj3hKC64SSE8uaNi8fULHPBMuVRIosyJrV/ZRgzpO0UFcY/cD 6KHg==
X-Gm-Message-State: AOJu0Yz3BJeoG57ZQMkkB4BoZGPKomCu/XyDRrsofLaI88fK5t86xotu DfesqThxb/quDLRl6ZIpfBBASeOyMcq977QM7Ph/8lFb9rWOtP4LHXIkqh2F8FI8JXUYTsgknhu 3uxGWZNbuQiq1urgE2WMZ4Q7A+eHYtZoDkxhV+59q8IQleNUHrL0=
X-Gm-Gg: ASbGncuxEhHg5Iw73THgcB6e9adL1xg48japJrSZmKHP2oet2Sac6qAbZ22zFAT2rp1 HCqxAqudp2t6FJ+/LzwxjpXrct95s6Wu07+kXSQI=
X-Google-Smtp-Source: AGHT+IFbvnuiJVNsoXUrGwuRdjTv2yZWRVNM+T0F8yrxR32ABPurIdAsFHvc8tMifSzzjc8tZmE0ZZ2dy8RENw416f0=
X-Received: by 2002:a2e:8e98:0:b0:302:4a61:8b85 with SMTP id 38308e7fff4ca-30251e87e26mr3696611fa.37.1734024959912; Thu, 12 Dec 2024 09:35:59 -0800 (PST)
MIME-Version: 1.0
From: Joseph Salowey <joe@salowey.net>
Date: Thu, 12 Dec 2024 09:35:48 -0800
Message-ID: <CAOgPGoCHnXZzzoAFT8GGmByr=7y1j5wM3ptPc4_JBF3FhtVNmQ@mail.gmail.com>
To: "<tls@ietf.org>" <tls@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000c48319062916251d"
Message-ID-Hash: PJ4ACM662OJFYVIGTFPEMFPQG5HBEESF
X-Message-ID-Hash: PJ4ACM662OJFYVIGTFPEMFPQG5HBEESF
X-MailFrom: joe@salowey.net
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
X-Mailman-Version: 3.3.9rc6
Precedence: list
Subject: [TLS] 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/aqDkGSSCj5FOMaR7hYp9rgS6AAI>
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>

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