Subject: [TLS] When/why is the RSA premaster secret version rollback check needed?

From: "Brian Smith" <[email-masked]>
Date: Tue, 10 Aug 2010 13:02:14 -0500

What attack is thwarted by checking the version number in the premaster
secret that isn't thwarted by the Finished message hash & HMAC? If a server
finds this check problematic for some reason, what alternate countermeasures
could it take to achieve a same security assurance? 

At first, I thought it was enough to disable SSL 2.0 support. But, the TLS
1.2 specification actually requires *stricter* checks when the hello
versions are newer than it does when the hello versions are older. I am
having trouble understanding how this makes sense.

My intuition tells me that for a server that doesn't support SSL 2.0, the
premaster secret version check must either be unnecessary, or it must be
caused by some problem inherent to RSA key exchange that I've overlooked,
since the Finished message protects the entire contents of hello messages
(including the version numbers), and this specific check isn't done for
other key exchange methods.

Any help-even simply a link to the discussion that motivated the addition of
the version number into the RSA encrypted premaster secret-would be greatly
appreciated.

Thank you,

Brian

---

From: Michael D'Errico <[email-masked]>
Date: Tue, 10 Aug 2010 11:29:36 -0700

> secret that isn’t thwarted by the Finished message hash & HMAC?

I think it is a "belt and suspenders" approach to security, which is a
good thing.  It probably isn't strictly necessary.  You probably realize
that with DH-based cipher suites, the premaster secret can not include a
version; thus if the version check was actually critical, then DH would
be less secure than RSA.  I haven't heard anybody claim that to be true.

Mike

---

From: "Brian Smith" <[email-masked]>
Date: Wed, 11 Aug 2010 00:56:18 -0500

Michael D'Errico wrote:
> > What attack is thwarted by checking the version number in the
> > premaster secret that isn't thwarted by the Finished message hash &
HMAC?
> I think it is a "belt and suspenders" approach to security, which is a
good thing.
> It probably isn't strictly necessary.  You probably realize that with
DH-based
> cipher suites, the premaster secret can not include a version; thus if the
version
> check was actually critical, then DH would be less secure than RSA.  I
haven't
> heard anybody claim that to be true.

I guess the RSA encrypted premaster secret version check (REPMSVC) does
provide a mechanism for protecting version rollbacks even in the event that
an enabled SSL/TLS version's finished hash is be ineffective. But, the
finished hash is required for cipher suite rollback prevention, secure
renegotiation, defense against the Bleichenbacher/Klima attacks, defense
against version rollback attacks for non-RSA key exchange methods, and
probably more. The REPMSVC doesn't offer any of these protections, so it
seems it is now useless. 

In certain common situations, the TLS 1.2 spec's suggested defense against
the Klima attack exacts a notable performance penalty. Skipping the version
check completely can result in a notable savings on *every* RSA handshake,
completely avoid the Klima attack, and apparently prevent interoperability
problems with IE8. It seems clear to me that the pros and cons of
permanently disabling the check outweigh the potential benefits. However, I
am very eager to hear arguments to the contrary, in the event I am
overlooking something. Again, feedback is greatly appreciated.

Thanks again,
Brian