This underscores the need for flexible security that doesn't rely on magic numbers. If an algorithm needs a number that can't be one of the obvious ones (0, 1, 2, 3, 2^x - 1, largest prime < 2^x) it should be generated.
Why can't those primes be calculated on the fly? Checking a number for being within a certain distance of a power of two is well within the programming capability of a freshman CS student.
> I don't know enough about DH to know if that's really the case here or if it's merely done to avoid having to compute fresh large primes, but I'm going to guess there's a good reason for it.
Given the incentives involved, I see strong reason to believe this is not the case.
You're assuming that that's the only criteria for a bad prime, but as this article points out, it's not.
> Given the incentives involved, I see strong reason to believe this is not the case.
Incentives where? The incentives by nearly everybody involved in making crypto is to be secure. The NSA wants to be able to break crypto, but the NSA didn't write the software that uses these primes (e.g. Apache).
From the article...
> Unlike prime numbers in RSA keys, which are always
> supposed to be unique, certain Diffie-Hellman primes
> are extremely common.
As to the technical reason why the DH parameters were reused - speed and efficiency. A DH key exchange would take longer if you had to generate those parameters each time.