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. LAKE recently removed PSK authentication completely as it does not produce smaller messages and comes with severe privacy and deployments problems. Increasing code size (a few kB) and slightly increased computation/latency was not seen as a big problems. Looking at the IANA TLS registry, I am surprised to see that psk_dhe_ke and especially psk_ke are both marked as RECOMMENDED. If used in the initial handshake, both modes have severe privacy problems, and psk_ke does not give PFS, thus making pervasive monitoring much easier. If groups keys are used, additional security problems arise. All TLS 1.2 cipher suites without (EC)DHE has for good reasons been marked as NOT RECOMMENDED. I have recently seen several people arguing that the inclusion of PSK in TLS 1.3 means that the use external PSKs are now recommended. I don't think that was the intension of the TLS WG. I strongly think psk_ke should be NOT RECOMMENDED, except for resumption. Irrespectively of what ‘Y’ in the recommended column actually means, people are and will read it as recommended to use. Cheers, John _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
