Re: [exim-dev] Bug#475194: D-H parameter generation is All W…

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.

Some of the original flame:

Marc Haber <mh+debian-packages@???> wrote:
> On Wed, Apr 09, 2008 at 10:34:00AM -0400, sacrificial-spam-address@??? 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. Section 39.3 conflates them with the 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. Since the Debian package
doesn't generate an RSA key at all, the restrictive permissions looked
like blatant cluelessness.

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

The only requirement for the parameters 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.

(As I mentioned earlier, the Debian package no longer generates an RSA
key, and I can't find anything in src/tls-gnu.c that uses such a key,
but there does appear to be somethink in tls-openssl.c. So I'm a bit
confused about that part of things.)