Handshake differs greatly between SSLv2 and SSLv3. All versions of TLS (1.0, 1.1, 1.2) use the SSLv3 format and although they add some new options and features they don't alter the basic flow relevant to DROWN. Although formatted differently, the security content of SSLv2
ClientMasterKey is the same as SSLv3/TLS
ClientKeyExchange when using RSA keyexchange, in that both contain an RSA (specifically PKCS1v1.5) encryption of the only secret information needed to determine the keys, which is exactly why DROWN works.
The critical difference is SSLv2 ServerVerify. Quoting from the DROWN paper:
2.2 SSL and TLS ...
The SSLv2 handshake protocol. ...
The server responds with a
consisting of the
challenge $r_c$ encrypted with
Our attack exploits the fact the server always decrypts
an RSA-PKCS#1 v1.5 ciphertext, computes the
server_write_key, and immediately responds with a
ServerVerify message. The SSLv2 standard implies
this message ordering, but does not make it explicit. However,
we observed this behavior in every implementation
The TLS handshake protocol. ... or SSLv3, ...
The two main details relevant to our attacks are: ...
* After receiving the
the server waits for the
in order to authenticate the client.
This is why SSLv2 provides the Bleichenbacher-style oracle but SSLv3 or TLS does not, so DROWN can use the SSLv2 oracle to break SSLv3 or TLS sessions.