On Sun, Mar 20, 2016 at 06:36:09AM +0000, Peter Gutmann wrote: > Dave Garrett <davemgarr...@gmail.com> writes: > > >It would be a lot simpler, safer, and interoperable to just mandate use of > >the Extended Master Secret Extension [RFC 7627]. > > > >https://tools.ietf.org/html/rfc7627 > > Yeah, in hindsight it makes more sense, I'll update the draft, although the > update may not get in before the IETF freeze. I was trying to avoid having to > run two parallel hashing operations throughout the handshake (the other one > being for the Finished message), but EMS is just a much more comprehensive > solution (like EtM, it's one of those things where you think "why wasn't this > added to TLS years ago") even if it means running two lots of hashing.
Well, if you have suitable implementation for it, the hash in EMS is over prefix of what hash in Finished is over (so if you can finalize multiple times, you can get away with just one computation). Also, TLS 1.2 ServerKeyExchange signature is not taken over ClientHello and ServerHello. This was famously exploited for FREAK and LOGJAM (and then there is the DHE vs. ECDHE issue). Sadly, this was found out too late for changing EMS extension to extend the signature. Then there is the problem that DHE parameter sizes are not negotiated. This is severe enough problem that it renders DHE effecively unusable in some contexts[1][2]. And if you want ciphers that are actually not fragile, look at various MRAE algorithms, not generic composition of CBC mode with HMAC (I have seen even cryptographers get the latter wrong). [1] TLS 1.3 doesn't completely fix this: Even if TLS 1.3 itself has negotiated DHE parameter sizes, there is nothing preventing down- negotiation to TLS 1.2, followed by server dumping some bad para- meter sizes (forcing client to either break connection or being vuln- erable to downgrade attacks). [2] If you wonder why Chrome is deprecating DHE, it is exactly this problem. -Ilari _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
