(background) It wasv mentioned in the paper that for TLS, RSA PKCS#1 v1.5 is used to encapsulate the 48-byte premaster secret exchanged during the handshake. Does means that a random padding string PS is prepended to the 48-byte premaster secret to this formatted massage
([00] || [02] || PS || [00] || pms)
before the actual RSA encryption is done?
Yes, with the correction that PS is random nonzero. (I'm sensitive to this because I once had to interop-test with a system that didn't correctly exclude zero from PKCS1-type2 padding, resulting in several percent of cryptograms causing spurious test failures.)
(1st question) How does the decryption oracle in the SSLv2 server differentiate between TLS-conformant ciphertexts and SSLv2-conformant ciphertexts, since the padded TLS plaintext also contains ([00]||[02]) as the 1st 2 bytes?
As described in 2.2, for SSLv2 the PKCS1-encrypted value is $mk_{secret}$ whose size depends on the ciphersuite selected.
As described in 3.2, the SSLv2 oracle (server) checks "$m$ starts with
0x00 02 followed by non-null padding bytes, a delimiter
byte 0x00, and a master_key $mk_{secret}$ of correct byte
length $k$" where k depends on the ciphersuite; examples given are 5 to 24.
48 is not equal to the k value for the selected SSLv2 ciphersuite, or indeed any of them.
3.3 confirms this: "But since no SSLv2 cipher suites have
48-byte key strengths, this means that a valid TLS ciphertext
is invalid to our oracle O." The rest of 3.3 explains the (clever) process used to find a mathematically-related and SSLv2-conformant ciphertext.
(2nd question) Why is it that one has to transform a RSA PKCS#1 v1.5 TLS conformant ciphertext to RSA PKCS#1 v1.5 SSLv2 conformant ciphertext before being fed to the Blechenbacher oracle?
Because the SSLv2 oracle only gives a distinguishable response for an SSLv2-conformant ciphertext. For all TLS-valid ciphertexts it gives a randomized response from which no information can be extracted -- but the entire purpose of an oracle is to leak information.
