Hiya, On 03/09/2019 18:58, Richard Barnes wrote: > Finally, to Stephen's question of analysis -- This doesn't affect the DTLS > analysis. All that's being done here is that another value is being > encrypted with the keys from the DTLS handshake. In that regard, it's like > any other application protocol. In the current approach, where we use a > different handshake type, it is true that the EKTKey messages are fed into > the DTLS transcript hash, which could affect future keys. But this > shouldn't allow any undue influence on those future keys, because unless > the hash function has a preimage attack, an attacker can't choose a > malicious input that leads to a particular value.
Thanks. However, we're previously seen unexpected comments from people who do such analyses (e.g. "if you did it <this other way> it'd be easier to analyse"), so personally I'd prefer we still had that kind of analyst do that kind of analysis. I think there's real value in not lowering the bar for TLS changes like this, and this does still smell like that to me. Cheers, S.
0x5AB2FAF17B172BEA.asc
Description: application/pgp-keys
signature.asc
Description: OpenPGP digital signature
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
