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

[Nick Harper <[e-mail]>]

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

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

Yet other implementations get this correct. If one's goal is to increase
adoption of psk_ke, it would seem to be a better use of time to work with
those implementers to fix those bugs instead of arguing that the spec
should be changed to work around those bugs (which would decrease security
for other parts of the ecosystem).

>
> > PSK only key exchange lacks forward secrecy.
>
> That's not quite accurate.


https://www.rfc-editor.org/rfc/rfc8446#section-2.2 disagrees.

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

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.

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. psk_ke further
optimizes the handshake by removing all asymmetric crypto, at the cost of
forward secrecy. 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.

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

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.