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

[David Woodhouse <[e-mail]>]

On Sat, 2020-09-19 at 11:30 +0000, John Mattsson wrote:
> Hi,
> 
> Recent discussions in 3GPP, ACE, and LAKE about the use of symmetric
> keys for authentication and key exchange made me think about the
> future role of external PSK in TLS.
> 
> https://mailarchive.ietf.org/arch/msg/ace/A60CFIvUohBwAXi_JuMKkQanZak/
> 
> I authored RFC 8442 because I believe PSK+ECDHE is needed for legacy
> systems. Due to the major privacy, security, and deployment
> limitations with PSK, I see little need to use PSK (besides
> resumption) in new systems, except for the use case in RFC 8773.

Some VPN protocols (e.g. Cisco AnyConnect) attempt to establish a DTLS
session in parallel with an existing TLS session, to avoid TCP-over-TCP 
where possible.

Cisco does it by fabricating a DTLS session (details exchanged over the
existing authenticated TLS channel) and then "resuming" it. Using this
method, the DTLS protocol version and all options are hard-coded when
the session is fabricated. This makes me sad.

In the open source implementation of client/server we have extended the
protocol to exchange a PSK over the existing TLS session, then
negotiate DTLS the "normal" way using that PSK.

That's a lot cleaner (IMO) and seems like a valid use case for PSK.