I can speak a little to how the reuse of keys will affect existing TLS 1.3 proofs and analyses.
First it is worth noting that most TLS 1.3 proofs do not consider hash function agility, and say nothing about deploying TLS 1.3 in parallel to TLS 1.2 (with some exceptions like [1], [2]) So, the good news is that these proofs do not care much about how PSKs or signature keys are used in TLS 1.2. The bad news is that this means that, in general, reusing the same keys in 1.2 and 1.3 is insecure. Even just within TLS 1.3, if we use the same PSK with two versions of HKDF that use different hash algorithms, we would need a strong “joint” assumption on both these hash functions. Assuming that the HKDF hash algorithm is fixed (either by the standard or for each key), we can then use the Universal PSK trick to specialize the PSK for other parameters (such as hash algorithm used for the TLS transcript). But from what I understand the HKDF hash algorithm is itself determined by the cipher suite hash algorithm, so I need to think whether the specialisation provides any formal guarantees. Secondly, TLS 1.3 analyses that account for downgrade attack (like [1],[2]) show that the downgrade countermeasures in TLS 1.3 are sufficient to protect TLS 1.3 sessions, but only under some conditions. In particular, [2] shows that it is only safe for an endpoint to reuse keys between TLS 1.2 and TLS 1.3 if (1) even in TLS 1.2, the endpoint only supports PSK-based or signature-based ciphersuites (i.e. no RSA encryption) (2) even in TLS 1.2, the endpoint only supports “strong” hash functions (3) in TLS 1.2 and 1.3, all the hash functions used within signatures and MACs are *jointly* collision resistant (i.e. you cannot easily find b such that H2(b) == H1(a), for different supported hash functions H1 and H2) In summary, the security proofs for TLS 1.3 require fairly strong conditions on what modes and algorithms of TLS 1.2 can be safely supported by the same client/server. It is probably worth writing these down as security considerations, and we can quickly discuss this with the academics who did the various proofs. -Karthik [1] Downgrade Resilience in Key-Exchange Protocols (IEEE S&P 2016) https://eprint.iacr.org/2016/072 [2] Verified Models and Reference Implementations for the TLS 1.3 Standard Candidate (IEEE S&P 2017) https://hal.inria.fr/hal-01528752v2/ > On 20 juil. 2018, at 08:08, Eric Rescorla <e...@rtfm.com> wrote: > > Karthik
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
