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

[Viktor Dukhovni <[e-mail]>]

On Mon, Mar 06, 2023 at 11:18:50PM -0800, Nick Harper wrote:

> > Basically, one way or another, PSK key exchange mode negotiation needs
> > to be interoperable by default.
> 
> Based on your first message, it sounds like you have identified an
> implementation where it is not interoperable. All of the spec language in
> the world won’t fix implementation bugs.

It isn't the only one.

> PSK only key exchange lacks forward secrecy.

That's not quite accurate.  Resumption via PSK-only key exchange is not
compromised by disclosure of the server's long-term private keys.  Yes,
disclosure of the short-term ticket encryption key can compromise a set
of sessions, and so clients are free to not offer "psk_ke".

> For general purpose libraries, defaulting to PSK-DHE with forward
> secrecy is the right choice for security.

Defaulting, sure, provided both sides offer it.  But defaulting
(interoperable) is different from exclusively offering only psk_dhe_ke
(not interoperable with clients offeringl only "psk_ke").

> (As you point out, a server that only supports DHE PSKs shouldn’t send
> new session tickets to a client that doesn’t support psk_dhe_ke, but
> that doesn’t contradict psk_dhe_ke only as being a sane default.)

Yes, but the more serious issue is that resumption is impossible,
sending an unusable ticket is only a minor nuisance.

> RFC 8446 provides the right building blocks, and delegates the choice of
> which to use to an application profile standard. There’s no need for any
> additional language in the TLS 1.3 spec to encourage or mandate the use of
> non-FS PSK modes.

I disagree, protocols need to be interoperable by default.  Features
that fragment clients and servers into non-interoperable islands of
compatibility are poorly designed.  This is why we have MTI code points,
and mechanisms to negotiate more preferred options.  We need both PSK
modes to be MTI and enabled by default, with the stronger chosen when
mutually supported and enabled.

> For applications where forward secrecy isn’t needed or the computation
> costs outweigh the security benefits, the application profiles for
> those use cases can encourage or mandate psk_ke.

This is not well understood or likely to happen.  For example, ADoT in
DNS (from iterative resolver to authoritative server, not user to
resolver) is a good candidate for psk_ke, but it is not possible to to
enable it, so as a non-trivial fraction of servers are psk_dhe_ke-only,
negotiating "psk_ke" based on the client's preferred mode does not work.
This is a protocol issue first, and implementation issue second.

> > Meanwhile, when there's no other choice, keep using TLS 1.2.

[ See thread on TLS 1.2 deprecation, it is much too early to consider. ]

--
    Viktor.