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 <[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. 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. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
