Hey all, So TLS 1.2 has a mechanism for PSKs. We attempted to mirror it in TLS 1.3 via the external PSK mechanism, repurposing the resumption flow. But the security proof requires PSKs be associated with a specific hash for key separation. We use distinguishing labels in the key schedule, but if that key is fed into a completely different KDF, analysis must additionally consider interactions between the KDFs.
The hash constraint, however, makes it difficult to actually use external PSKs in applications. Usually the TLS stack and its configuration evolves somewhat independently from the calling application. But now the PSK provisioning process must short-circuit part of the TLS parameter negotiation, despite it likely being implemented in a separate library altogether. This is a leaky abstraction. It also complicates server parameter selection. We've found the cleanest algorithm is selecting the cipher suite first, and then ignoring the PSKs that don't match. This is simple and avoids weird behavior if a session is renewed across preference changes. However, this only works for resumption PSK: if the session mismatches, a full handshake is always an option. With external PSKs, the application usually expects the PSK to be mandatory. Finally, some libraries (e.g. OpenSSL) already TLS 1.2 PSK APIs and wish to transparently upgrade to TLS 1.3. The specification does not explicitly say if a TLS 1.2 PSK may be used directly as a TLS 1.3 PSK and I believe some implementations are doing that. However that violates TLS 1.3's key separation assumptions in the same way as mixing hashes: the TLS 1.2 PRF is not the same as HKDF. It's a bit late to completely redo external PSKs in 1.3, but I believe we can fix this in a separate draft. The draft below proposes "universal PSKs" which derive independent hash- and version-specific secrets for TLS 1.3 (and later) as needed. For existing TLS 1.2 PSKs, it includes a compatibility derivation to go from TLS 1.2 PSKs to universal PSKs. (Thanks to Karthikeyan Bhargavan, Matt Caswell, Eric Rescorla, and Victor Vasiliev for discussions which led to this design. Any mistakes in it are mine.) Thoughts? If the WG likes this design, I would suggest: - Most folks who want to use TLS 1.3 with external PSKs should probably design their protocols to provision universal PSKs instead, after it stabilizes. - Folks who want to use TLS 1.3 with existing TLS 1.2 PSKs should use the compatibility derivation in this draft, after it stabilizes. - Folks who want to ship TLS 1.3 before then and have a TLS 1.2 PSK API should not use the 1.2 PSK as a 1.3 PSK. For now, just turn TLS 1.3 off by default if that API is used and, in a future release, use the compatibility derivation after it stabilizes. - If it's not too late to clarify whether TLS 1.3 believes whether PSKs are version-specific, it would be good to do that. David PS: Looking over the draft now, I see I mixed up some of the RFC 4279 and RFC 5246 citations. I'll fixed that in the next iteration. ---------- Forwarded message --------- From: <internet-dra...@ietf.org> Date: Thu, Jun 14, 2018 at 3:21 PM Subject: New Version Notification for draft-davidben-tls-universal-psk-00.txt To: David Benjamin <david...@google.com> A new version of I-D, draft-davidben-tls-universal-psk-00.txt has been successfully submitted by David Benjamin and posted to the IETF repository. Name: draft-davidben-tls-universal-psk Revision: 00 Title: Universal PSKs for TLS Document date: 2018-06-14 Group: Individual Submission Pages: 7 URL: https://www.ietf.org/internet-drafts/draft-davidben-tls-universal-psk-00.txt Status: https://datatracker.ietf.org/doc/draft-davidben-tls-universal-psk/ Htmlized: https://tools.ietf.org/html/draft-davidben-tls-universal-psk-00 Htmlized: https://datatracker.ietf.org/doc/html/draft-davidben-tls-universal-psk Abstract: This document describes universal PSKs (Pre-Shared Keys) for TLS. Universal PSKs abstract the TLS 1.3 requirement that each PSK can only be used with a single hash function. This allows PSKs to be provisioned without depending on details of the TLS negotiation, which may change as TLS evolves. Additionally, this document describes a compatibility profile for using TLS 1.3 with PSKs provisioned for the TLS 1.2 PSK mechanism. Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
