Loading ...
Sorry, an error occurred while loading the content.

295210Re: Exim, DH, GnuTLS & interop

Expand Messages
  • Jerry
    Sep 3 5:15 AM
      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-user@...
      _____________________________________________________________________
      TO REPORT A PROBLEM see http://www.postfix.org/DEBUG_README.html#mail
      TO (UN)SUBSCRIBE see http://www.postfix.org/lists.html
    • Show all 10 messages in this topic