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

On Mon, Mar 6, 2023 at 9:30 PM Viktor Dukhovni <ietf-dane@dukhovni.org>
wrote:

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

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.

PSK only and PSK-DHE modes offer two fundamentally different security
properties. PSK only key exchange lacks forward secrecy. For general
purpose libraries, defaulting to PSK-DHE with forward secrecy is the right
choice for security. (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.)

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

>
>
> 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 mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>