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 <[EMAIL PROTECTED]> wrote: > On Wed, Apr 09, 2008 at 10:34:00AM -0400, [EMAIL PROTECTED] 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.) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
