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.
