IETF Logo Mail Archive

[TLS] Re: [EXTERNAL] Re: Disallowing reuse of ephemeral keys

Christian Huitema <huitema@huitema.net> Thu, 12 December 2024 20:07 UTC

Return-Path: <huitema@huitema.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 AD009C180B7E; Thu, 12 Dec 2024 12:07:22 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.813
X-Spam-Level:
X-Spam-Status: No, score=-0.813 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, HTML_MESSAGE=0.001, MIME_HTML_ONLY=0.1, MIME_HTML_ONLY_MULTI=0.001, MIME_QP_LONG_LINE=0.001, MPART_ALT_DIFF=0.79, 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_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=neutral reason="invalid (public key: not available)" header.d=mfg.outbound
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 I6TAmoQHewSZ; Thu, 12 Dec 2024 12:07:22 -0800 (PST)
Received: from semfq02.mfg.siteprotect.com (semfq02.mfg.siteprotect.com [64.26.60.183]) (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 C01EBC151520; Thu, 12 Dec 2024 12:07:21 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=mfg.outbound; s=default; h=To:In-Reply-To:Cc:References:Message-Id:Date: Subject:Mime-Version:From:Content-Transfer-Encoding:Content-Type:reply-to: sender:bcc; bh=qBNdhJ11k/ai3L5mTIkzOnUPi4q/4VP8+nCPcKLo6+s=; b=KzotXB9m1i2cb1 kaundVllP4ycGKi2OfTZe4JYPAZ8D7jr6hGMEjeVbs0WSh5QkiYzI2pCvaAVSBM/K8fYgS4CMJHx2 XXPyYYBJpm/ps8fpZ5fLiJFjCg2LoOOd++QmU+kT3Yeh0x3YTKMd1nqTxF9PCsyDEQeJ18Srr1Ma4 ydiwGrGvevG6qzcMMQKacNI3qYAldMJkSW/Lcuxv+R7VTxHLyhewZlJQY29wtodBStVJ76COcSI0E JJkUS2AInv+t2hqGtJbWvdjXf06tNBHWrOMfJgaOwoKkjj8fd215BOGqk69CnhU3z0Eh/CEv9ohzK hleDHpksNM5c+KYlMPyQ==;
Received: from smtpauth01.mfg.siteprotect.com ([64.26.60.150]) by se02.mfg.siteprotect.com with esmtp (Exim 4.92) (envelope-from <huitema@huitema.net>) id 1tLpSw-00B9nu-W9; Thu, 12 Dec 2024 15:07:20 -0500
Received: from smtpclient.apple (unknown [172.56.104.14]) (Authenticated sender: huitema@huitema.net) by smtpauth01.mfg.siteprotect.com (Postfix) with ESMTPSA id 4Y8NmM2Hrkz163Nqh; Thu, 12 Dec 2024 15:07:15 -0500 (EST)
Content-Type: multipart/alternative; boundary="Apple-Mail-A2B0D4F2-603B-467C-9F81-50772CF70F80"
Content-Transfer-Encoding: 7bit
From: Christian Huitema <huitema@huitema.net>
Mime-Version: 1.0 (1.0)
Date: Thu, 12 Dec 2024 12:07:03 -0800
Message-Id: <F215DE9E-D11B-47BC-A3AB-14CA38481ADF@huitema.net>
References: <LV8PR21MB4158CEABE28A5068931F32788C3F2@LV8PR21MB4158.namprd21.prod.outlook.com>
In-Reply-To: <LV8PR21MB4158CEABE28A5068931F32788C3F2@LV8PR21MB4158.namprd21.prod.outlook.com>
To: Andrei Popov <Andrei.Popov=40microsoft.com@dmarc.ietf.org>
X-Mailer: iPhone Mail (22B91)
Authentication-Results: mfg.siteprotect.com; auth=pass smtp.auth=huitema@huitema.net
X-Originating-IP: 64.26.60.150
X-SpamExperts-Domain: mfg.outbound
X-SpamExperts-Username: 64.26.60.150/31
Authentication-Results: mfg.siteprotect.com; auth=pass smtp.auth=64.26.60.150/31@mfg.outbound
X-SpamExperts-Outgoing-Class: ham
X-SpamExperts-Outgoing-Evidence: Combined (0.17)
X-Recommended-Action: accept
X-Filter-ID: Pt3MvcO5N4iKaDQ5O6lkdGlMVN6RH8bjRMzItlySaT8P6BbY0Xk2+/ejCZDiVyZ3PUtbdvnXkggZ 3YnVId/Y5jcf0yeVQAvfjHznO7+bT5zBAzwSIZR2Os4N+s/lrMMMEU/zYEDVP22whYY8WpoGHSp3 cwQrbFTrcmiDymUFLpHiopyvp8tiAKGBcHi3TCVMPOTQLl2OCveXR6NnOhTC6C811eD9VOpwFN3X yMXhVqFuS+7HsJnGEK51f31kknP158fMnqZUTt7CyKlJUh+zhkq2Vqz2uu+0oz93xUsNWoojXP8n NjVpS0g8HWBVEiUU0XoM34WhfqULuLpa1SGSTB48LhT9u0er7PoYJ6KSyDX8HCjSNR/3uP0+E3aD Jn9NX84x44glEc12EAGIFg+F928ZzWKlrVQV2iQRN7xapU8Y4L7u6QJ/jXXAPItovk04cEIrpGzy Q2S1Ym7hOzWKeSo1M+TSg3TNDI3/M5s9/ot3ko3rrae7IifWc6pL546YUVQwaYLh3di89W/ji5ia hyCgJgyv93tC61cbiLYl3RDVyICLsR5K5dMUmWojBkc73WOGcz8xu9rZctX8sgTNontYPoQ0Jj65 L3gjKqG/DdzcvLyZt0OWix2dhra38zsA31/E3ahF5MMcDI7KdpjQKSV3q/2WkmYCjITWVA9mFlrM COiqfA4iVraWl17/cRld+A+d5aHmS5uVrFlVCgDjvCk4xAm9D8KTeKJT7gNACPcOFimDDEQNC4fs Y2m/Ye7W+MQBVTljYEWDlEfHS11XYpLX4tfgF3TNL/Dh2wWKSzi35pM0QJMI2eTehdw3kw/SyCyD fNQJlEtNNQAEcE0w83e+aLcfbuZ90UFYuKvj7bvveLRFJ4MoRpzJEjk7iN2i82cKxZFAhCYB6hPz A4TbjG1TEY6ANME+CeSYRICl142iNJstiP6vPi78MbmFBe1S+lLsee6aeidy5k//OFLz/4tWgUqV RC9akT7YiMFoTPgLsL1AHp1kxnJDKlNfML6jUV8ShebT8U8Xw9HTDfreWQzNaImMIxXwb8aAKgE9 0Jm+o19CLNrfHhC92ahtOmc6fpRRNBRV6cMlQ5JHR3RfTGu1/wl/f+Tjkn2bQ/A8pE7pmGXCOLP7 0W6tjDmybQR0UM6c833vP+Zo0SOxd5kRCQDk5nWIiIcthdTaotkIarQx9rxOIu3CfAuBPlivwnte tOslUUxmPdNgSNM57A1S43oOGyEsNEVGlVphGeDtVD4=
X-Report-Abuse-To: spam@se02.mfg.siteprotect.com
Message-ID-Hash: 5PVKF7CZMACUNWMX23BRHRMRQKV4AJMX
X-Message-ID-Hash: 5PVKF7CZMACUNWMX23BRHRMRQKV4AJMX
X-MailFrom: huitema@huitema.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
CC: IETF TLS <tls@ietf.org>
X-Mailman-Version: 3.3.9rc6
Precedence: list
Subject: [TLS] Re: [EXTERNAL] 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/1-li1Q9vDRNHAZcZgVhiWGMuIOE>
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 like keeping as they are. Disallowing only makes sense if that prohibition can be enforced, and one of the peer refuses the connection if it detects key reuse. Would we want to do that? And, even if we wanted to accept the cost of refusing connections, could individual nodes actually detect reuse by a peer? 

-- Christian Huitema 

On Dec 12, 2024, at 10:11 AM, Andrei Popov <Andrei.Popov=40microsoft.com@dmarc.ietf.org> wrote:



+1 in favor of option1.

 

Cheers,

 

Andrei

 

From: Russ Housley <housley@vigilsec.com>
Sent: Thursday, December 12, 2024 9:43 AM
To: Joe Salowey <joe@salowey.net>
Cc: IETF TLS <tls@ietf.org>
Subject: [EXTERNAL] [TLS] Re: Disallowing reuse of ephemeral keys

 

I prefer option 1.

 

Russ



On Dec 12, 2024, at 12:35 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
  1. 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)
  1. 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