IETF Logo Mail Archive

[TLS] Re: Disallowing reuse of ephemeral keys

Filippo Valsorda <filippo@ml.filippo.io> Thu, 12 December 2024 17:53 UTC

Return-Path: <filippo@ml.filippo.io>
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 997D8C151076 for <tls@ietfa.amsl.com>; Thu, 12 Dec 2024 09:53:43 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.003
X-Spam-Level:
X-Spam-Status: No, score=-2.003 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_VALIDITY_RPBL_BLOCKED=0.001, RCVD_IN_VALIDITY_SAFE_BLOCKED=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_PASS=-0.001, 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=filippo.io header.b="bSMstzH/"; dkim=pass (2048-bit key) header.d=messagingengine.com header.b="k93jOJ8M"
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 G-hYSXbf0GHp for <tls@ietfa.amsl.com>; Thu, 12 Dec 2024 09:53:38 -0800 (PST)
Received: from fhigh-b4-smtp.messagingengine.com (fhigh-b4-smtp.messagingengine.com [202.12.124.155]) (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 ietfa.amsl.com (Postfix) with ESMTPS id E530BC14CE5E for <tls@ietf.org>; Thu, 12 Dec 2024 09:53:38 -0800 (PST)
Received: from phl-compute-07.internal (phl-compute-07.phl.internal [10.202.2.47]) by mailfhigh.stl.internal (Postfix) with ESMTP id D207A254022F for <tls@ietf.org>; Thu, 12 Dec 2024 12:53:37 -0500 (EST)
Received: from phl-imap-13 ([10.202.2.103]) by phl-compute-07.internal (MEProxy); Thu, 12 Dec 2024 12:53:37 -0500
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=filippo.io; h=cc :content-type:content-type:date:date:from:from:in-reply-to :in-reply-to:message-id:mime-version:references:reply-to:subject :subject:to:to; s=fm3; t=1734026017; x=1734112417; bh=2wKNmaM4ow QKecMN6/xCf/gvgItBhj/iyR6mNJ81QHI=; b=bSMstzH/gFbpkIl/R/lwbAhaxD 6MYIN3j01WEjcDnC5nMOOgRh5kvpzfn5RXxul8rmHo+Jdm0yRXuernCMTzMop4SU fGnheU4RaWFhKCUmzy34FnT5vsbgomHV9I05CZWyoeUYB5cn5IkVWVvJe+V9/Z8C /yD2wn4BvEiKdDhd0CMCq25zu4hgUmz4mhO5qXcSki9OHuduZor8Iye/EbAZn4u4 IHNFfSYhbSaFD3ELsnu8622mnpq0btxYgn72YJVDgxvlbsVbKZ18SZsM2r+RqW4K YtDNADyduAGinxOe5KWXJp9zszKLBrWlsZZkx55TDfKFK8npCSad62vaO97A==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:content-type:date:date :feedback-id:feedback-id:from:from:in-reply-to:in-reply-to :message-id:mime-version:references:reply-to:subject:subject:to :to:x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; t= 1734026017; x=1734112417; bh=2wKNmaM4owQKecMN6/xCf/gvgItBhj/iyR6 mNJ81QHI=; b=k93jOJ8MOuN9A3lwxkeP82Rve42YxFEA/S1pwVcWmBE+wwJPU1m 6p2JKQ1uUeMYlElILVS8QdmkR0h+LOVwRXLQ74kgElsxsFrBYMUStTgAUtUWdV3A GA85tMcibSK6K3ocQx7RBwx9VhB/mg/66uqyg31Ko57wl0N/9iwostyCXBOJcuav 9EFC1o5y/2sp0NuVv0DxBDb8BKZkX88Hu+6vSg3MyLYlDKszrPicjDHUi0ukBwqr V6qKzR+XuUp8thTjE53KF9/hIRbln1vy+M4k/xJEuOzEKo6u7sn+H+ENEs586UAR uz8GfmyoYI3mVv/UJ6KRcXXFQGqCvyw9aeA==
X-ME-Sender: <xms:ISNbZ9v55MGhqFttr-zFM8aWkfbAKyOdgyT4sq1y39__c6hCK7jWaw> <xme:ISNbZ2dA0879Gmh10_o3eIHG_zc4YIhLF-f-Dqvyb6FDasmw6o-y1beV-h6i6e4yD jP8aONtlF-D80n0Ig>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeefuddrkeehgddutdegucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdggtfgfnhhsuhgsshgtrhhisggvpdfu rfetoffkrfgpnffqhgenuceurghilhhouhhtmecufedttdenucenucfjughrpefoggffhf fvkfgjfhfutgesrgdtreerredttdenucfhrhhomhepfdfhihhlihhpphhoucggrghlshho rhgurgdfuceofhhilhhiphhpohesmhhlrdhfihhlihhpphhordhioheqnecuggftrfgrth htvghrnhepjeefudekffdtvdefhffhledvhedtledvudeljeeukeekgfekteegueevvddt teevnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomhepfh hilhhiphhpohesmhhlrdhfihhlihhpphhordhiohdpnhgspghrtghpthhtohepuddpmhho uggvpehsmhhtphhouhhtpdhrtghpthhtohepthhlshesihgvthhfrdhorhhg
X-ME-Proxy: <xmx:ISNbZwxOI4TEnyXBltFeVOoRVTpE80oMR_7myJkNU2-x9r9rrN_Ggw> <xmx:ISNbZ0NvGpv_taAyVmxDfmykPgg5PaaSpRV_lV8khygWhnaT-WtKyw> <xmx:ISNbZ99VP7JHShf3MSYXaFzYpupSbHQMI05CIkHurZG4MpJ40rTBeA> <xmx:ISNbZ0WGmNifQPd0crE3NxyUxtpuogHJL9bSuFaG0EXtQnJZS0DV6w> <xmx:ISNbZ6GgD9pbw4UQHiKHWSkkqXG3VDXLUZSy02efCWb8CozVNgbdL8Fp>
Feedback-ID: i2e91459c:Fastmail
Received: by mailuser.phl.internal (Postfix, from userid 501) id 62A691F00086; Thu, 12 Dec 2024 12:53:37 -0500 (EST)
X-Mailer: MessagingEngine.com Webmail Interface
MIME-Version: 1.0
Date: Thu, 12 Dec 2024 18:53:17 +0100
From: Filippo Valsorda <filippo@ml.filippo.io>
To: tls@ietf.org
Message-Id: <bf28dd19-0534-4403-8e20-50bcbbc0fcdd@app.fastmail.com>
In-Reply-To: <CAOgPGoCHnXZzzoAFT8GGmByr=7y1j5wM3ptPc4_JBF3FhtVNmQ@mail.gmail.com>
References: <CAOgPGoCHnXZzzoAFT8GGmByr=7y1j5wM3ptPc4_JBF3FhtVNmQ@mail.gmail.com>
Content-Type: multipart/alternative; boundary="be30247fbbea44c5a4547410a7c09e4a"
Message-ID-Hash: P2IGAC7YDLFLKH2CNBCBF2FNONM6G3Q7
X-Message-ID-Hash: P2IGAC7YDLFLKH2CNBCBF2FNONM6G3Q7
X-MailFrom: filippo@ml.filippo.io
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] 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/RBfwbOu7vv3SQavv0cxw9Z2ejVc>
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 support some variation of 2 or 3, depending on what encounters the most resistance. I agree there is no technical reason to disallow it for e.g. X25519MLKEM768 and not X25519, but in practice it might be easier to set a new rule for something that's still being rolled out and still a draft.

Both ECDH and KEMs support key share (or public key) reuse *in theory* but in practice it makes implementation issues much more likely to be practically exploitable, and the hypothetical performance gain of reuse is marginal. The spec should defend against that and point implementations towards the safer course of action.

As always, there is no protocol police, so implementations that want to risk shooting their foot off will be able to do so, but they will be off-spec, which is a useful signal.

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