On Thu, 2018-06-14 at 15:46 -0400, David Benjamin wrote: > 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. I don't think that TLS1.3 has strict key separation assumptions, and they are nowhere spelled out. For example, RSA keys can be used for RSA-PSS or RSA PKCS#1 1.5 signatures or RSA encryption. > 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? It feels that's this is too little too late. Implementations which support PSKs will switch to TLS1.3 irrespective of this proposal. If this proposal takes on, we will have some implementations which support universal PSKs and others which don't leading to interoperability problems which we wouldn't have otherwise. regards, Nikos _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
