What's the purpose of Server Key Exchange when using Ephemeral Diffie-Hellman?

Question

What's the purpose of ServerKeyExchange when using ephemeral Diffie-Hellman? In this case, the ClientHello advertised EDH and EECDH (and not anonymous protocols), and the server selected TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA in its ServerHello.

According to RFC 5246, Section 7.4.3:

  This message will be sent immediately after the server Certificate
  message (or the ServerHello message, if this is an anonymous
  negotiation).

  The ServerKeyExchange message is sent by the server only when the
  server Certificate message (if sent) does not contain enough data
  to allow the client to exchange a premaster secret. This is true
  for the following key exchange methods:

     DHE_DSS
     DHE_RSA
     DH_anon

I understand RSA is being used for authentication (and not key transport). But since Diffie-Hellman is being used, both sides contribute material to the final master_secret. So there's no need for a message that allows the client to contribute more material earlier for the premaster_secret.

What's the purpose of ServerKeyExchange when using ephemeral Diffie-Hellman?

Answer 1

In Diffie-Hellman, the client can't compute a premaster secret on its own; both sides contribute to computing it, so the client needs to get a Diffie-Hellman public key from the server. In ephemeral Diffie-Hellman, that public key isn't in the certificate (that's what ephemeral Diffie-Hellman means). So the server has to send the client its ephemeral DH public key in a separate message so that the client can compute the premaster secret (remember, both parties need to know the premaster secret, because that's how they derive the master secret). That message is the ServerKeyExchange.

I'm not sure what you mean by "a message that allows the client to contribute more material earlier" in regards to the ServerKeyExchange. The ServerKeyExchange doesn't let the client contribute more material; the client sends a ClientKeyExchange in all TLS suites. The point of the ServerKeyExchange is to let the server contribute more material to the key exchange, by letting it send additional information not in the certificate.

About "backtracking to premaster secret:" The premaster_secret is the immediate outcome of key exchange. Key exchange in TLS never produces a master_secret directly; this is because the TLS designers wanted the master secret to have a consistent length with entropy spread throughout, so that your key derivation code doesn't have to worry about how key exchange happened. Different key exchange methods produce differently formatted shared secrets, so you always have to convert the premaster secret to a master secret of 48 bytes. There's no real concept of "backtracking," as the master secret isn't derived until key exchange is finished.