Does DH parameter file need to be unique per private key?

Question

There is scant information available online on the DH parameters used in DHE ciphers (and the kind that's available is aimed at cryptographers, not systems administrators). Basically, as a sysadmin, I would like to know whether the dhparam.pem file needs to be unique per each private key, or can be shared between various TLS sites hosted on the same server.

Answer 1

TL;DR Yes, parameters (not keys) can be shared.

First, don't say "parameter keys". Parameters and keys are related but different. The whole point of parameters is that they define a mathematical group within which keys are chosen and used. Generating parameters is costly (moderately so for DH and DSA, much more so for ECC); generating a key for given parameters is much cheaper. Further, a main point of DHE ciphersuites is that your SSL implementation generates a new ephemeral key for every connection. If you are running just one server with a fixed set of DH parameters, and that server handles more than one connection from one client using DHE, you are already using multiple keys with the same parameters. And similarly for ECDHE, but more on that below.

There is no harm (added) to connection security in using the same parameters for multiple servers as long as the parameters are not chosen or influenced by an attacker or otherwise grossly bad -- in which case they should not be used for even one server. The only case I see for multiple parameters is if you have some (possibly virtual) servers which must support (typically older) clients which can only handle DH 1024-bit, which now has a fairly small safety margin, while other servers want the greater margin -- and/or compliance with standards such as NIST 800-57 if applicable -- of 2048-bit or more.

(Added) One caveat: if you are trying to conceal that servers are under common administration, using shared but otherwise unique parameters gives a clue that their admins might be the same -- but not a strong one, because it could be they are simply using the same software. For example, Apache for a long time had a builtin default set of DHE parameters, and before Snowden and Logjam almost everybody used that default without thinking about it, so all those servers used the same parameters (when they used DHE at all) even though most of them were wholly unrelated and separate. (Similarly, researchers who have scanned the net for common RSA moduli or factors -- which is a security weakness, and a very bad one -- have tracked some of them down to particular hardware or software products, with no other commonality.)

For ECDHE (and ECDHA and ECDH and ECDSA, although those weren't your question) there are standard parameter sets -- commonly called named curves -- that are much easier to use and also more widely/reliably interoperable, so you should not even try to generate your own. As of now it appears best to always use P-256 or maybe P-384, the two standard curves (out of dozens) "blessed" by NSA in its Suite B profile.

See pretty-much-duplicates:

• What are the implications of using the same DH parameters in a TLS server?
• Can someone explain a little better what exactly is accomplished by generation of DH parameters?
• How often should the DHE p and g factors be recycled?

UPDATE: since this has been necroed, I'll add that (for TLS) rfc7919 in 2016 recommends use of standardized parameters (the same for all users, chosen by a variant of the 'nothing up my sleeve' method from IKE rfc2412 & rfc3526), and TLS 1.3 rfc8446 in 2018 requires standardized groups for both classic/integer/Zp/modp/FFC DHE and ECDHE, dropping the 'explicit' EC option in 4492 that no one used anyway. (And 1.3 generally requires [EC]DHE, because it dropped the plain-RSA and static-[EC]DH forms of keyexchange, though there is still PSK for the few cases that is manageable.)