Re: [TLS] TLS 1.3 servers and psk_key_exchange_modes == [psk_ke]?

Viktor Dukhovni <ietf-dane@dukhovni.org> Wed, 08 March 2023 02:50 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 8CDAAC14F5E0 for <tls@ietfa.amsl.com>; Tue, 7 Mar 2023 18:50:57 -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 Ongd5cQjvs0M for <tls@ietfa.amsl.com>; Tue, 7 Mar 2023 18:50:56 -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 76C72C14EB17 for <tls@ietf.org>; Tue, 7 Mar 2023 18:50:55 -0800 (PST)
Received: by straasha.imrryr.org (Postfix, from userid 1001) id 8AEE9126CD4; Tue, 7 Mar 2023 21:50:54 -0500 (EST)
Date: Tue, 07 Mar 2023 21:50:54 -0500
From: Viktor Dukhovni <ietf-dane@dukhovni.org>
To: tls@ietf.org
Message-ID: <ZAf4DqWEnUPNDP0k@straasha.imrryr.org>
Reply-To: tls@ietf.org
References: <Y/1ngz1ITlYds2WP@straasha.imrryr.org> <SY4PR01MB6251E03AE8A05E38FA8A3F0DEEB79@SY4PR01MB6251.ausprd01.prod.outlook.com> <ZAbL6AP8uzgb60NB@straasha.imrryr.org> <CACcvr=mS9DM__U-7=SEg58YFCJzfhheckbY==QNRy2KFCY8x2A@mail.gmail.com> <ZAdPGnIJe63I035Z@straasha.imrryr.org> <CACcvr=mUACw8uHG0zmGZsUSFFdHq9+i7hZx6ST6RFsdWX_WsUA@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <CACcvr=mUACw8uHG0zmGZsUSFFdHq9+i7hZx6ST6RFsdWX_WsUA@mail.gmail.com>
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/SNvqq6Eox81BUj2uzNOiU0H84Bs>
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: Wed, 08 Mar 2023 02:50:57 -0000

On Tue, Mar 07, 2023 at 03:49:13PM -0800, Nick Harper wrote:

> It is interoperable by default, if the implementations follow the spec. If
> implementations don't follow the spec, no amount of spec language will fix
> their behavior.

What specific changes would you recommend in say the OpenSSL
implementation?  Just not sending the useless tickets?  Fine, we've
saved a bit of bandwidth, but haven't really solved the problem.

We have somewhat different interoperability expectations, because I
expect resumption to work under typical conditions, which would include
clients sending just "psk_ke".  Unless the server has a good reason to
expect all clients to always request "psk_dhe_ke", it should support
"psk_ke", leaving the client the option to negotiate "psk_dhe_ke" or use
"psk_ke" if preferred.

> Having both PSK modes MTI is a bad idea. Resumption is an optimization:
> psk_dhe_ke removes an asymmetric cryptographic operation to verify the
> certificate chain, while retaining forward secrecy.

Resumption is an important optimisation, it can make the difference
between a scalable service and a degraded or unusable service.

> psk_ke further optimizes the handshake by removing all asymmetric
> crypto, at the cost of forward secrecy.

Only if the server's ticket key (which should be a *short-term* secret
on the scale of minutes to hours) is compromised.  Once the ticket key
is discarded, psk_ke is no less forward_secret than psk_dhe_ke.  The
latter is also compromised if the server's DHE private key leaks (yes
it is supposed to be single use, and securely erased from memory, ...
but reality may differ).

> An implementation could decide that it wants the certificate verified
> on every connection (and support no resumption), or could decide that
> it only wants to support connections with forward secrecy (and not
> support psk_ke). Making any PSK modes MTI reduces security.

There's no downgrade attack, if both sides want psk_dhe_ke, they get it.
If some application or private deployment never needs psk_ke resumption,
fine.  But in the absence of specific knowledge a generic client using
TLS to reach some random server should be able to perform resumption
without the sort of friction that turning up forward-secrecy to 11
introduces.  The client *should* still offer psk_dhe_ke where it makes
sense, and servers *should* then use DHE resumption, but if the client
has good reason to choose "psk_ke" it should not be punished for its
choice to optimise for performance.

> This isn't a protocol issue. This is an implementation issue (buggy
> implementations sending psk_dhe_ke NSTs in response to psk_ke ClientHellos)
> and an ecosystem issue.

But sending the unusable tickets isn't the problem, the problem is that
non-DHE resumption is unavailable by default.  Is that an implementation
bug or not?  And when client therefore offers both modes to avoid not
getting any resumption, it always gets DHE resumption.  So why is
"psk_ke" even defined, if it is in practice almost never usable.

Right now it requires prior consent on both sides to enable "psk_ke",
and prior knowledge by the client that the server will do so.  That
reall does not scale.

-- 
    Viktor.