Re: [TLS] The future of external PSK in TLS 1.3

[David Benjamin <[e-mail]>]

There are two different code points involved in TLS 1.3 PSK, and I think
there may be some mixup here:
1. Whether TLS 1.3 psk_ke should be marked N
2. Whether TLS 1.3. psk_dhe_ke should be marked N

Avoiding psk_ke does not remove compatibility with any authentication
method. psk_ke and psk_dhe_ke use the same PSKs. The difference is whether
the handshake mixes an additional (EC)DH exchange into the key schedule.
We've *already* marked TLS_PSK_WITH_AES_128_GCM_SHA256 with an N, so it
seems to me psk_ke with an external PSK should be similar. Handshakes using
psk_ke with an external PSK incorporate no secrets in the key exchange
apart from a (often long-lived) external symmetric secret. Compromise that
secret, and all traffic ever authenticated with that PSK is compromised.
Resumption PSKs use short-lived keys, so psk_ke is less immediately
disastrous but given the equivalent construction in TLS 1.2 has forward
secrecy issues <https://www.imperialviolet.org/2013/06/27/botchingpfs.html>,
marking it as N across the board seems a good idea to me. (BoringSSL does
not implement psk_ke for this reason. Looks like Go and NSS do not
implement it either.)

psk_dhe_ke I suppose depends on how one interprets "specific use case", so
I don't feel very strongly here.

David

On Wed, Sep 23, 2020 at 11:37 AM Salz, Rich <rsalz=
[e-mail]> wrote:

> I agree with Hannes’s reasoning.
>
>
>
> I am also concerned about devolving TLS to be just Web browser/server.
>
>
> _______________________________________________
> TLS mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/tls
>