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

Alicja Kario <hkario@redhat.com> Mon, 16 December 2024 13:42 UTC

Return-Path: <hkario@redhat.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 1A3F6C169428 for <tls@ietfa.amsl.com>; Mon, 16 Dec 2024 05:42:16 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.253
X-Spam-Level:
X-Spam-Status: No, score=-2.253 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.148, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H2=-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_NONE=0.001, T_SCC_BODY_TEXT_LINE=-0.01] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=redhat.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 W7sWLY0KFyDR for <tls@ietfa.amsl.com>; Mon, 16 Dec 2024 05:42:15 -0800 (PST)
Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) (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 805BFC180B78 for <tls@ietf.org>; Mon, 16 Dec 2024 05:42:15 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1734356534; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=Lqr7c2PSgHg/GeucZ9bXbB3ZhxQDsE+dQFYCatdzM7c=; b=ImUy/Yzl0jvLFogRPq5SS+zwcMzWn5YGdFcK0vb8f+dkODA1J7BZZkGH+KRu9CC2vlhyIM YbB8Il61K8OTBDw3P0pgkAR7IsIJXgiFNugwxAAyQe2YyRnTA6lT4SVKjldyUnzRD5ru6+ iKy0BEXtsYBVxmR60HA7pRVy90TaIyY=
Received: from mail-wm1-f70.google.com (mail-wm1-f70.google.com [209.85.128.70]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-358-tGssaNplNu2MeXM_0wczqQ-1; Mon, 16 Dec 2024 08:42:13 -0500
X-MC-Unique: tGssaNplNu2MeXM_0wczqQ-1
X-Mimecast-MFC-AGG-ID: tGssaNplNu2MeXM_0wczqQ
Received: by mail-wm1-f70.google.com with SMTP id 5b1f17b1804b1-436289a570eso32830155e9.0 for <tls@ietf.org>; Mon, 16 Dec 2024 05:42:12 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1734356532; x=1734961332; h=content-transfer-encoding:user-agent:organization:references :in-reply-to:message-id:mime-version:date:subject:cc:to:from :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=YGicT0aJbp2Ob0UUm6RQYP0lpWFpeP8/jzE8bDjskNE=; b=NM/UaNMTb5qg20Ghvc/9x8+SXjW/+uMI7ZHScIkwNbC0SyxPsIRmQnhNAZGZ5s815K yuAwcgj9LUnxt7Qu1Vv4k11YB40pHihwkpicJgCoLqF1MKBgb04AxWTl90FwtHfuJ2sG WcPepE4C5U6RAF3fTXi3dOqtipcqXizcoCAj4cMrz+MHu20OMjHgL+tIKDXRnVDaHjQT 82CafLO4XWKYwnmWQ95+x8k6fPLJHxwMrb14CpRDIK9KQJxOcdp6OQ1ayXJxWF7pTKi6 bcpWHhj+6DBW5taKGw8ZWoTw6tAh4s7DXPSCAT6bMrukc6rwzBvO1K/06V6UF9Q/++CM QDYw==
X-Forwarded-Encrypted: i=1; AJvYcCXelask5SbV9P4q/2h8e2PDraDQiGDgj+rqC1r1PNTQP0GoAFr4LotMGSkJnQti4TgU8BE=@ietf.org
X-Gm-Message-State: AOJu0YxEpu8rj40Szq5KyJpbhRmXdohRjj++wn/FPERiZkbTSUuUEkOm 8XyJqyM05jpFk5i6Ji9Uy/49QNyz8ShfEbTr0etjHNFCK9ax3gREKSSUM4ush2alcH+xWBKK//4 YcvOaRzJLaF/FfSG+QBk5AzR7G7Edc3ux6At6roXU
X-Gm-Gg: ASbGncsnOMKYD3X04n4fAmkaVf1tzscdqKxEHnASBiZ9/KHCnRKCOj85mip8P/NUgzm vJj0s3HoEk0wUyFNL0k0ETXvHka4YoeYOOZOXAbJo9RU/fUVewLeIdkbXW9WPYLo5XwMDaS+RfE 1tWCKOpv94INwPP3T6SxFFPAbZqyfLNv5qIuz8OwDp9MM8NS8Ll22bycqb+JYGprVCwnFsucIT4 vn9dz0vDGJ9r0+UTKKAGXYWS5ir5dMeaklqevRJA5bUeP/i7PpN5LmAsWpgiUCg1H+oSDmBgUIU hKDz
X-Received: by 2002:a05:600c:6549:b0:434:f0df:9fd with SMTP id 5b1f17b1804b1-4362aa1b061mr134975985e9.2.1734356531906; Mon, 16 Dec 2024 05:42:11 -0800 (PST)
X-Google-Smtp-Source: AGHT+IGml7zz3arpe6TNDSES9ZGu53Y2OpvoSgL0crdkaMmfISWQrjPKL4kbque9jYIzBZbLAMK2Aw==
X-Received: by 2002:a05:600c:6549:b0:434:f0df:9fd with SMTP id 5b1f17b1804b1-4362aa1b061mr134975695e9.2.1734356531483; Mon, 16 Dec 2024 05:42:11 -0800 (PST)
Received: from localhost (ip-94-112-13-93.bb.vodafone.cz. [94.112.13.93]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-43636063c85sm85316275e9.19.2024.12.16.05.42.11 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 16 Dec 2024 05:42:11 -0800 (PST)
From: Alicja Kario <hkario@redhat.com>
To: Christian Huitema <huitema@huitema.net>
Date: Mon, 16 Dec 2024 14:42:10 +0100
MIME-Version: 1.0
Message-ID: <50935d5a-3072-4db5-ab38-244b2d97cfeb@redhat.com>
In-Reply-To: <F215DE9E-D11B-47BC-A3AB-14CA38481ADF@huitema.net>
References: <LV8PR21MB4158CEABE28A5068931F32788C3F2@LV8PR21MB4158.namprd21.prod.outlook.com> <F215DE9E-D11B-47BC-A3AB-14CA38481ADF@huitema.net>
Organization: Red Hat
User-Agent: Trojita/0.7-git; Qt/5.15.15; wayland; Linux; Fedora release 40 (Forty)
X-Mimecast-Spam-Score: 0
X-Mimecast-MFC-PROC-ID: NTA7JK00q0Sr_3i8IXK69UlOz6TJ0qLB3OAHGtyr9Fw_1734356532
X-Mimecast-Originator: redhat.com
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: quoted-printable
Message-ID-Hash: I6T35YJQHIJZSEIVBIDHVCKYCYQJSTXN
X-Message-ID-Hash: I6T35YJQHIJZSEIVBIDHVCKYCYQJSTXN
X-MailFrom: hkario@redhat.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: Andrei Popov <Andrei.Popov=40microsoft.com@dmarc.ietf.org>, IETF TLS <tls@ietf.org>
X-Mailman-Version: 3.3.9rc6
Precedence: list
Subject: [TLS] Re: [EXTERNAL] 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/2hd7EPk1huGzSZWZFk8jCU49Ygw>
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>

No, the specification definitely can, and should, specify behaviours that
are unenforcable.

When there are preferred or recommended ways of doing something, we should
absolutely put that in writing.

On Thursday, 12 December 2024 21:07:03 CET, Christian Huitema wrote:
> 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:
>  
> 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
> 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)
> 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
>  

-- 
Regards,
Alicja (nee Hubert) Kario
Principal Quality Engineer, RHEL Crypto team
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purkyňova 115, 612 00, Brno, Czech Republic