[TLS] RFC5487 PSK Key Exchange Algorithm with SHA-256/384. Premaster secret if ciphersuites negotiated for TLS V1.2?

[Fox Arcadia <[e-mail]>]

Hello

For the ciphersuites defined in RFC 5487
<http://tools.ietf.org/html/rfc5487>  3.1

PSK Key Exchange Algorithm with SHA-256/384

CipherSuite TLS_PSK_WITH_AES_128_CBC_SHA256        = {0x00,0xAE};
CipherSuite TLS_PSK_WITH_AES_256_CBC_SHA384        = {0x00,0xAF};
CipherSuite TLS_PSK_WITH_NULL_SHA256               = {0x00,0xB0};
CipherSuite TLS_PSK_WITH_NULL_SHA384               = {0x00,0xB1};

How is the premaster secret formed if the negotiated version is TLS 1.2?

according to RFC 4279 <http://tools.ietf.org/html/rfc4279> Pre-Shared
key ciphersuites for TLS:

The premaster secret is formed as follows: if the PSK is N octets
   long, concatenate a uint16 with the value N, N zero octets, a second
   uint16 with the value N, and the PSK itself.

      Note 1: All the ciphersuites in this document share the same
      general structure for the premaster secret, namely,

         struct {
             opaque other_secret<0..2^16-1>;
             opaque psk<0..2^16-1>;
         };

...

 Note 2: Using zeroes for "other_secret" effectively means that
      only the HMAC-SHA1 part (but not the HMAC-MD5 part) of the TLS PRF
      is used when constructing the master secret.  This was considered
      more elegant from an analytical viewpoint than, for instance,
      using the same key for both the HMAC-MD5 and HMAC-SHA1 parts.  See
      [KRAWCZYK <http://tools.ietf.org/html/rfc4279#ref-KRAWCZYK>] for
a more detailed rationale.


but if using a PRF defined in TLS V1.2, then HMAC-MD5 is not used but
the HMAC defined by the PRF.

And, in that case, part of the used premaster is zeroes.

should we in that case reuse PSK for other_secret?

Thanks