Re: [TLS] TLS 1.3 servers and psk_key_exchange_modes == [psk_ke]?
Viktor Dukhovni <ietf-dane@dukhovni.org> Tue, 07 March 2023 05:30 UTC
Return-Path: <ietf-dane@dukhovni.org>
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 2403DC14CE2F for <tls@ietfa.amsl.com>; Mon, 6 Mar 2023 21:30:20 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.199
X-Spam-Level:
X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
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 GjTSWr4hPwy2 for <tls@ietfa.amsl.com>; Mon, 6 Mar 2023 21:30:18 -0800 (PST)
Received: from straasha.imrryr.org (straasha.imrryr.org [100.2.39.101]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 624D5C14CE2B for <tls@ietf.org>; Mon, 6 Mar 2023 21:30:17 -0800 (PST)
Received: by straasha.imrryr.org (Postfix, from userid 1001) id 52B741262E5; Tue, 7 Mar 2023 00:30:16 -0500 (EST)
Date: Tue, 07 Mar 2023 00:30:16 -0500
From: Viktor Dukhovni <ietf-dane@dukhovni.org>
To: tls@ietf.org
Message-ID: <ZAbL6AP8uzgb60NB@straasha.imrryr.org>
Reply-To: tls@ietf.org
References: <Y/1ngz1ITlYds2WP@straasha.imrryr.org> <SY4PR01MB6251E03AE8A05E38FA8A3F0DEEB79@SY4PR01MB6251.ausprd01.prod.outlook.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <SY4PR01MB6251E03AE8A05E38FA8A3F0DEEB79@SY4PR01MB6251.ausprd01.prod.outlook.com>
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/yFHR0PwXM5_0dtRIIYN6X60Ke80>
Subject: Re: [TLS] TLS 1.3 servers and psk_key_exchange_modes == [psk_ke]?
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <tls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tls/>
List-Post: <mailto:tls@ietf.org>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 07 Mar 2023 05:30:20 -0000
On 6 Mar 2023, at 8:13 pm, Peter Gutmann <pgut001@cs.auckland.ac.nz> wrote: > Not really sure how to fix this, although at the moment "stay with TLS > classic" seems to be the preferred option. There are three stages of fixes: 1. Update the protocol specification. 2. Fix the implementations. 3. Keep using TLS 1.2 until the fixed implementations are broadly adopted. Keeping in mind that LTS enterprise editions of Linux are lately supported for ~13 years, step 3 may take a while. Which is not to say that we should not start doing 1. and 2., but it is like planting an olive tree, the fruit will be enjoyed by future generations. The protocol specification needs to say something along the lines of: - Implementations MUST support both psk_ke and psk_dhe_ke. - Server operators SHOULD leave both modes enabled. - In closed environments, or specific applications where *all* clients are expected to and required to support psk_dhe_ke the required to enable psk_ke is relaxed to MAY. - Conversely, where no clients are expected to support psk_dhe_ke, the requirement to leave it enabled changes to MAY. - psk_dhe_ke is negotiated when supported by both sides, otherwise psk_ke is negotiated. - Clients SHOULD generally offer both modes in the client HELLO. - Clients MAY offer just one or the other when appropriate for the application in question, and can expect to interoperate with a "general purpose" server. Basically, one way or another, PSK key exchange mode negotiation needs to be interoperable by default. As for implementations, the code changes are not that difficult, but will take time to release, and then there's step 3... Meanwhile, when there's no other choice, keep using TLS 1.2. -- Viktor.
- [TLS] TLS 1.3 servers and psk_key_exchange_modes … Viktor Dukhovni
- Re: [TLS] TLS 1.3 servers and psk_key_exchange_mo… Peter Gutmann
- Re: [TLS] TLS 1.3 servers and psk_key_exchange_mo… Viktor Dukhovni
- Re: [TLS] TLS 1.3 servers and psk_key_exchange_mo… Nick Harper
- Re: [TLS] TLS 1.3 servers and psk_key_exchange_mo… Viktor Dukhovni
- Re: [TLS] TLS 1.3 servers and psk_key_exchange_mo… Nick Harper
- Re: [TLS] TLS 1.3 servers and psk_key_exchange_mo… Viktor Dukhovni
- Re: [TLS] TLS 1.3 servers and psk_key_exchange_mo… Nick Harper
- Re: [TLS] TLS 1.3 servers and psk_key_exchange_mo… Peter Gutmann
- Re: [TLS] TLS 1.3 servers and psk_key_exchange_mo… Viktor Dukhovni
- Re: [TLS] TLS 1.3 servers and psk_key_exchange_mo… Peter Gutmann