Bug#475194: D-H parameter generation is All Wrong

[sacrificial-spam-address at horizon.com]

I recently administered a stiff flaming to the Debian package maintainers
for exim4, and was rebuffed with the observation that the behaviour I was
complaing about was recommended by the exim specification, section 39.3.

Marc Haber <mh+debian-packages at zugschlus.de> wrote:
> On Wed, Apr 09, 2008 at 10:34:00AM -0400, sacrificial-spam-address at horizon.com wrote:
>> The entire premise of the script /usr/share/exim4/exim4_refresh_gnutls-params
>> is based on a serious misapprehension of the role of Diffie-Hellman
>> parmeters in performing encryption.
>
> It is, however, in accordance with upstream's recommendations.
>
>> I wish I could come up with a polite way to put this, but the entire
>> thing smells strongly of cluon deficiency.
>
> Point taken. Please give the same advice upstream and we'll follow
> once upstream changes their recommendations.

So I'd like to suggest that the advice in that section undergo some
considerable revision.

There appears to be a fundamental misapprehension about the role
of Diffie-Hellman parameters.  Unlike the RSA secret key (which is
actual secret key material and should not be called a "parameter"), the
D-H parameters are not key material, and do not need to be protected
from inspection.  In fact, they are sent in the clear to everyone who
initiates a TLS session.  So if, like the Debian package does, you don't
use the RSA key at all, there's no need to set restrictive permissions.

In the Diffie-Hellman algorithm, the actual key is chosen fresh for each
connection, and not stored on disk anywhere, ever.

The only requirement is that they must not be maliciously chosen; an
attacker who can choose the Diffie-Hellman modulus can make an attack
easier.

But there's no need to keep the values secret, any more than it's a secret
that SMTP uses port 25.

It's also not very important that the D-H parameters be changed often;
while changing them N times makes it N times as much work for an attacker
that wants to read ALL of your mail, it's better to just use a larger
prime and make it N times harder for an attacker to read ANY of your
mail.

In fact, many cryptographic standards just specify a menu of fixed
D-H parameters for all implmentations for all time (e.g. RFC3526).
Generating a set once at install time is also reasonable.  Changing it
daily is silly.

I might also mention that 1024 bits (which is O(2^80) operations to
break) is considered a bit small for serious security these days.
GNU TLS defaults to 2048 bits, a more reasonable default.