Hi John, I can only fully agree with Hannes's arguments!
PSK is in my experience for some constraint devices currently the only choice. Devices, which are able to execute a PSKs with ECDHE handshakes, will be able to use RPK. I'm not sure, if sometimes the arguments, not to recommend something, should be more differentiated. Pretty sure, outside IoT, there may be no reason left to use that. But inside IoT, it may take some more time until almost all device can use it. best regards Achim Am 20.09.20 um 13:18 schrieb Hannes Tschofenig:
John, The use of plain PSK makes a lot of sense because it provides the lowest footprint solution for really constrained systems. Given that the LAKE group wanted to focus on constrained IoT devices makes the decision by the group questionable. As you know, TLS 1.3 merged the handling of PSKs previously found in three different RFCs, namely session resumption, ciphersuites with PSK, and session resumption without server-side state into one solution. As such, there is not even extra cost associated with external PSKs. I have been arguing that a solution that uses PSKs with ECDHE, as you proposed in RFC 8442, is less useful because very constrained are not going to use the asymmetric crypto needed for the ECDHE. Those deployments could instead go directly to a raw public key solution instead. Ciao Hannes -----Original Message----- From: TLS <tls-boun...@ietf.org> On Behalf Of John Mattsson Sent: Saturday, September 19, 2020 1:30 PM To: TLS@ietf.org Subject: [TLS] The future of external PSK in TLS 1.3 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 IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you. _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
