On Mon, 2 Sep 2013 22:14:42 +0000 Viktor Dukhovni articulated: > On Mon, Sep 02, 2013 at 03:03:36AM +0000, Viktor Dukhovni wrote: > > > On Mon, Sep 02, 2013 at 01:25:02AM +0000, Viktor Dukhovni wrote: > > > > > If Peer Heinlein would be kind enough to post > > > the Exim version that exhibits the problem and any relevant > > > settings, that would help narrow down the problem. > > > > Also the version of GnuTLS with which Exim is linked. > > Looking at the source code of GnuTLS 3.2.4 (really master branch > from "git" which is 3.2.4 plus some new code) I see that with GnuTLS > priority strings the "Normal" security level defaults to a minimum > DH bit length of 2432, which is perhaps sound cryptography, but poor > engineering: > > typedef struct > { > const char *name; > gnutls_sec_param_t sec_param; > unsigned int bits; /* security level */ > unsigned int pk_bits; /* DH, RSA, SRP */ > unsigned int dsa_bits; /* bits for DSA. Handled > differently since > * choice of key size in DSA is > political. */ > unsigned int subgroup_bits; /* subgroup bits */ > unsigned int ecc_bits; /* bits for ECC keys */ > } gnutls_sec_params_entry; > > static const gnutls_sec_params_entry sec_params[] = { > {"Insecure", GNUTLS_SEC_PARAM_INSECURE, 0, 0, 0, 0, 0}, > {"Export", GNUTLS_SEC_PARAM_EXPORT, 42, 512, 0, 0, 0}, > {"Very weak", GNUTLS_SEC_PARAM_VERY_WEAK, 64, 727, 0, 0, 0}, > {"Weak", GNUTLS_SEC_PARAM_WEAK, 72, 1008, 1024, 160, 160}, > {"Low", GNUTLS_SEC_PARAM_LOW, 80, 1248, 2048, 160, 160}, > {"Legacy", GNUTLS_SEC_PARAM_LEGACY, 96, 1776, 2048, 192, 192}, > {"Normal", GNUTLS_SEC_PARAM_NORMAL, 112, 2432, 3072, 224, 224}, > {"High", GNUTLS_SEC_PARAM_HIGH, 128, 3248, 3072, 256, 256}, > {"Ultra", GNUTLS_SEC_PARAM_ULTRA, 256, 15424, 3072, 512, 512}, > {NULL, 0, 0, 0, 0, 0} > }; > > The point is that the TLS protocol does not support negotiation of > the DH parameters between client and server, so client enforcement > of strong DH parameters that exceed common practice is rather unwise. > > Clearly at least some versions of Exim work around the problem by > expliciting setting a floor of 1024-bits (which interoperates with > OpenSSL, ...). It seems there may be some versions of Exim in which > the work-around is absent or not effective. > > More fundamentally, this is a problem with GnuTLS pushing the > envelope too aggressively. Before TLS clients start being pedantic > about key lengths in auxiliary algorithms, most server implementations > need to be updated to implement said key lengths with corresponding > SSL cipher-suites. > > This means that the GnuTLS developers need to talk to the NSS, > OpenSSL, Microsoft Crypto API, ... developers and reach consensus > on server EDH implementations before rather than just field > non-interoperable clients and push the problem to users and > applications. This may require a TLSv1.3 revision in which > MODP DH key lengths are also negotiated (and more efficient > DH agreement is supported via DSA-style parameters with a > secure subgroup whose size is double the symmetric key size as > in the RFC 5114 groups).
Viktor, that is an extremely sound, well thought out approach. However, those happy folks at GunTLS rarely talk to or even acknowledge the "OpenSSL" folks. I have no idea what their feeling are towards Microsoft, etcetera, but I doubt that it is favorable. Personally, this is one reason I stear clear of GnuTLS whenever possible. Just my 2¢. -- Jerry ✌ postfix-u...@seibercom.net _____________________________________________________________________ TO REPORT A PROBLEM see http://www.postfix.org/DEBUG_README.html#mail TO (UN)SUBSCRIBE see http://www.postfix.org/lists.html