Hi all, As I mentioned at the mic today, there is a question that has been raised about whether it's wise to reuse an existing (TLS 1.2) PSK directly in the TLS 1.3 key ladder. At a high level, the reason why one might want to restrict this is that the security proofs for TLS 1.3 rely on the pre-shared key being only used with a single key-derivation function (our HKDF-using Derive-Secret), and TLS 1.2 uses a different key-derivation function, so formally the proofs do not hold. We don't currently know of a specifc attack against such reuse, of course, but perhaps it is prudent to restrict our usage to adhere to the verified scenarios.
This is somewhat timely, as if we do want to introduce a restriction, it would ideally be in the form of some text in the TLS 1.3 specification, which is very nearly done. It would be good to hear more opinions on this question, particularly from those who have worked on the formal verification directly. If I can attempt to summarize some discussion that occurred in the mic line today, Hannes was surprised that we would care, likening this case to the regular version negotiation, where we are happy to use the same certificate to sign messages for both TLS 1.2 and 1.3. David Benjamin points out that we explicitly go to the trouble of putting 64 bytes of 0x20 padding at the front of the content that gets signed for CertificateVerify, to enforce separation between the TLS versions. My own personal opinion is that we should enforce a domain separation between TLS 1.2 PSKs and TLS 1.3 PSKs; David Benjamin's "Universal PSKs" proposal seems like a potential mechanism by which to do so without doubling the provisioning needs. -Ben (with no hat) _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
