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

[Nick Harper <[e-mail]>]

On Tue, Mar 7, 2023 at 6:51 PM Viktor Dukhovni <[e-mail]>
wrote:

> 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.
>

I don't know the details of the OpenSSL implementation or the behavior of a
psk_ke only client attempting that resumption with an OpenSSL server. Not
sending the useless tickets sounds like the right fix. It also sounds like
we've solved the problem: In a case where a client that only supports
psk_key for resumption modes is talking to a server that only supports
psk_dhe_ke for resumption, useless information is no longer being sent over
the wire and the client will always attempt a full handshake.

>
> 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.
>

I expect resumption to work when both endpoints support the feature. TLS
has multiple options (thankfully TLS 1.3 has many fewer than TLS 1.2), and
only the full handshake is required. You're correct that the client should
have the option to negotiate psk_dhe_ke or psk_ke (or none at all) as
desired, and in the same vein the server has the option to negotiate
psk_dhe_ke or psk_ke (or decline resumption) as desired.

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

I don't disagree. In application profiles where the optimization makes a
critical difference, the resumption modes that make that difference should
be specified as MTI. The key here is that they should only be MTI in those
application profiles.

>
> 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.
>

Why should a client be allowed to force a server to accept psk_ke over
performing a full handshake? A server should be free to choose to always
perform forward secret handshakes. When a client that prefers psk_ke talks
to said server, it isn't being punished. The client is offered psk_dhe_ke,
and if it doesn't like that, it can always do a full handshake. Each peer
is entitled to their preferences, and the TLS handshake negotiates the best
option for both endpoints.

>
> > 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?


That's not an implementation bug, that's an ecosystem issue. As I said
earlier, all of the pieces are there in RFC 8446. People just have to
choose to use it.

TLS is used in many different ways by different application protocols.
Stating that a certain feature of TLS should be available in all TLS
implementations is a high bar to pass — it must be near universally useful.
Instead, each ecosystem that uses TLS can and should decide for itself
which features are useful. Actors in those ecosystems can choose their
implementations (or choose to create their own) based on the availability
of TLS features.