1

I've been reading about the Logjam attack on Diffie-Hellman and about how to secure our TLC-based web servers based on the recent findings.

The guide suggests that we create a Unique Diffie-Hellman group. As I understand the protocol, this group must be the same for only one TLS connection. That is, from the perspective of the protocol, the group could be generated each time a new TLS connection is made, even for the same client. (Though the computation time and resources needed to create a new prime would make this impractical.)

I want to be sure of the implications of this.

  1. There is no need to persist the generated group. If the server dies and the group die with it, there is no loss.
  2. Different subdomains can have different groups, even when using a wildcard certificate.
  3. Browsers will not warn users of changes to this group.
2

Your inferences are correct; in fact, they are more often expressed the other way round: while each instance (TLS handshake) uses its own group, it is possible to reuse the same group between instances, regardless of whether they are for the same server or a distinct server. All the Logjam business was about clients and servers using a weak group (because the modulus was too short); the reuse of that group by many servers merely extended the scope of the attack.

There is no relation whatsoever between the group and the certificate or domain; group parameters are sent by the server for each handshake, so that clients do not need to remember anything about that group -- and, in practice, clients do not try to remember anything about the group, so they won't do anything special if a given group is reused or not reused.

However, one must take into account that group generation is kinda expensive. It is not necessarily as long as what OpenSSL does, because OpenSSL insists on using a "safe prime", which is overkill here (and, arguably, not "safer" in any way than a non-safe prime, because the terminology is merely traditional). Yet, producing a new group is still a matter of a few seconds of CPU, so you do not want to do that for each incoming connection. What could be done is generating fresh DH parameters upon server start -- thus, the parameters would not have to be saved in any file.

Pragmatically, existing Web servers (say, Apache) can read parameters from a file, and the guide you link to advocates generating a DH group unique to your server. The main value in generating your own group is that it allows you to generate a strong group, i.e. with a large enough modulus. That the group is not shared by other servers is only of secondary importance.

Note that for elliptic curves, everybody works with the same group (i.e. the same curve), because deployed implementations are specialized for that specific curve(*) and cannot handle any other. If group reuse was really an issue, then elliptic curves would have to be deactivated ASAP. Fortunately, reuse is not a problem.

(*) Actually two curves, NIST's P-256 and P-384, which are part of NSA Suite B; for some reason, this suite is increasingly taken by browser vendors as some kind of Gospel, to be followed to the letter, otherwise the gods will strike you with lightning.

0

Correct on all counts. The specific group being used has nothing to do with the server's (or user's) identity and can be changed at any time.

A 2048-bit group should be adequate for now, and if you have your own unique group it's extremely unlikely anyone would ever use the resources to do all of the pre-computation needed to attack it, even when computers get fast enough that 2048 bits is feasible. It's going to be a very expensive attack for a long time.

So there's no need to change it once you've created it, but if you need to regenerate it for some reason, no harm.

SRP is a password-authenticated DH-style protocol, and with that you would not want to change the group parameters, as doing so would invalidate the verifiers for all users (so their passwords would not work). That is not how DH works (where normally only the server is authenticated, using another mechanism independent of the DH group).

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.