TLS-conformant ciphertexts and SSLv2-conformant ciphertexts for Blechenbacher attack for DROWN attack This is regarding the published paper on the DROWN attack (https://drownattack.com/drown-attack-original-report.pdf)

It was 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?

If yes, I have 2 questions

(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? 

(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?

Thanks in advance!
(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.