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 ✌
[email protected]
_____________________________________________________________________
TO REPORT A PROBLEM see http://www.postfix.org/DEBUG_README.html#mail
TO (UN)SUBSCRIBE see http://www.postfix.org/lists.html
