Do you require a special type of certificate for using Diffie Hellman as the key exchange protocol in SSL?

Question

In Diffie Hellman key exchange technique both the parties agree on a common parameter g then they generate their private parameters a and b . Then they exchange g^a and g^b. now they can calculate the common secret key g^ab.
But my question is how do they agree on the parameter g. Is it specified in the certificate? If yes does it require a special type of certificate and what information is there in this type of certificate?

Answer 1

You don't need a special certificate for Ephemeral Diffie-Hellman key exchange, but you need the Server Key Exchange message. You need a special certificate for fixed DH. As the TLS specification says:

• In Section 7.4.3:

  The server key exchange 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

  It is not legal to send the server key exchange message for the
  following key exchange methods:

       RSA
       DH_DSS
       DH_RSA

Meaning of this message:

  This message conveys cryptographic information to allow the client
  to communicate the premaster secret: either an RSA public key with
  which to encrypt the premaster secret, or a Diffie-Hellman public
  key with which the client can complete a key exchange (with the
  result being the premaster secret).

• In Appendix A.5 (about non-ephemeral DH cipher suites):

The following CipherSuite definitions are used for server- authenticated (and optionally client-authenticated) Diffie-Hellman. DH denotes cipher suites in which the server's certificate contains the Diffie-Hellman parameters signed by the certificate authority (CA). [...]

• In Appendix F.1.1.3:

When Diffie-Hellman key exchange is used, the server can either supply a certificate containing fixed Diffie-Hellman parameters or use the server key exchange message to send a set of temporary Diffie-Hellman parameters signed with a DSS or RSA certificate. Temporary parameters are hashed with the hello.random values before signing to ensure that attackers do not replay old parameters. In either case, the client can verify the certificate or signature to ensure that the parameters belong to the server.

Note that certificates with DH parameters are rather rare anyway.

Stephen Henson (from OpenSSL) said the following (admittedly a long time ago):

I've asked all over the place and I've yet to see a single example of a DH certificate. From this I can conclude they aren't very common.

Nelson Bolyard (from Mozilla NSS) said the following more recently:

[...] I ask because I don't know of ANY public CA that issues such certs today. The last CA I knew of that did was the US DoD's CA that issued certificates for Fortezza cards.

I suspect there is little demand for these certificates. It would require more work from the CAs, it's just as easy to use EDH nowadays, and the cipher suites that can use them are not widely supported. The latest Java 7 list of supported cipher suites doesn't list any DH_RSA or DH_DSS cipher suites (only DH_anon and EDH).

Answer 2

There are two natural ways to do it.

1. The specification can identify a set of pre-defined groups. The group parameters for each one are hard-coded in the software used by both endpoints. The public key then specifies which of those groups it is intended for use with. In the case of Diffie-Hellman, the group parameters are g and p, so the group identifier in the public key determines the value of g. Since the group identifier is in the public key, it is included within the certificate.

2. Alternatively, the group parameters themselves (g and p) can be included in the certificate, as part of the public key.

Either way works. Either way, the information in the certificate allows you to determine the proper value of g and p to use. Beyond that, there's nothing special required.