On Fri, Jul 20, 2018 at 08:42:47AM -0400, David Benjamin wrote: > > (I suspect using the same key with TLS1.2-PRF-SHA256 and HKDF-SHA256 is > probably *more* risky than mixing HKDF-SHA256 and HKDF-SHA384. I don't > think we actually believe SHA256 and SHA384 give related output. It's just > nice to avoid the assumption. Whereas TLS1.2-PRF-SHA256 and HKDF-SHA256 > actually a chance of misbehavior. Perhaps it's worth doing that analysis?)
TLS 1.3 does this with PSK: HMAC(<zeroes>, PSK) And TLS 1.2 does: HMAC(<expanded PSK>, <some data>) (where <some data> actually depends on <expanded psk>). Now, it is possible that there is second similar block in there, but that uses the same <expanded PSK>. However, noteworthy point is that there is only two ways to end up in situation where the effective key in TLS 1.2 is all zeroes: 1) <expanded psk> is longer than hash block and is preimage of 0. Finding such thing is supposed to be infeasible. 2) The PSK is empty. However, the <some data> on TLS 1.2 side is not empty in this case (it starts with gunk from HMAC that involves at least both randoms). Also, empty PSK is not secure. The definition of HMAC is: H(C(key) XOR opad | H(C(key) XOR ipad, data)) Which preserves collision resistance on C(key) and data. Now, C(key) is not collision resistant. However, the only possible cases where C(key) can collide are the two above. So it seems to me that TLS 1.2 and TLS 1.3 compute independent things from PSK values, in all practical cases. -Ilari _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
