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.
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
