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

Re: Exim, DH, GnuTLS & interop

Expand Messages
  • Viktor Dukhovni
    ... 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
    Message 1 of 10 , Sep 2, 2013
    • 0 Attachment
      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.
    • Jerry
      On Mon, 2 Sep 2013 22:14:42 +0000 ... Viktor, that is an extremely sound, well thought out approach. However, those happy folks at GunTLS rarely talk to or
      Message 2 of 10 , Sep 3, 2013
      • 0 Attachment
        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
      • Phil Pennock
        ... Hash: RIPEMD160 ... Okay, I have identified the root cause. The systems that need to be placated are older Debian installs, and the method should be
        Message 3 of 10 , Sep 3, 2013
        • 0 Attachment
          -----BEGIN PGP SIGNED MESSAGE-----
          Hash: RIPEMD160

          On 2013-09-01 at 19:02 -0400, Wietse Venema wrote:
          > Second, we have to be mindful that Postfix and Exim are not the
          > only MTAs in existence. If placating Exim results in the loss of
          > interoperability with other MTAs, then we may have to reconsider
          > our approach.

          Okay, I have identified the root cause. The systems that need to be
          placated are older Debian installs, and the method should be broadly
          compatible.

          Debian used to patch, in their build system, the value passed to
          gnutls_dh_set_prime_bits() from 1024 to 2048. This is the value of the
          size of the DH parameters which is the "minimum considered acceptable".
          So Debian broke interop with "66_enlarge-dh-parameters-size.dpatch".

          Those maintaining Exim/Postfix setups should upgrade Exim to a recent
          version; after my overhaul back in 4.80, Debian stopped changing the
          value in their patches.

          The most compatible thing I know of for Postfix users to do is to
          generate DH parameters of size 2048, or very slightly larger, but *not*
          larger than 2236, which was for some time the NSS value of
          DH_MAX_P_BITS.

          If anyone knows of an MTA with which interop would be broken by using
          server DH parameters of size 2048, please do let me know.

          - -Phil
          -----BEGIN PGP SIGNATURE-----

          iEYEAREDAAYFAlImO3EACgkQQDBDFTkDY39a6ACaA2XfA32nQ/x4m83xpFEjoB7r
          zK0AmQGZ9HSdaNELVjWQ+YaOZhXMMN0c
          =vd9e
          -----END PGP SIGNATURE-----
        • Peer Heinlein
          Am 03.09.2013 21:41, schrieb Phil Pennock: Hi, ... Great. Thanks to Phil and Viktor for their great work. Really THANKS. Debian should release a security fix
          Message 4 of 10 , Sep 3, 2013
          • 0 Attachment
            Am 03.09.2013 21:41, schrieb Phil Pennock:


            Hi,

            > Debian used to patch, in their build system, the value passed to
            > gnutls_dh_set_prime_bits() from 1024 to 2048. This is the value of the
            > size of the DH parameters which is the "minimum considered acceptable".
            > So Debian broke interop with "66_enlarge-dh-parameters-size.dpatch".
            >
            > Those maintaining Exim/Postfix setups should upgrade Exim to a recent
            > version; after my overhaul back in 4.80, Debian stopped changing the
            > value in their patches.

            Great. Thanks to Phil and Viktor for their great work. Really THANKS.

            Debian should release a security fix update for their old packages...
            That would be the best, fastest and most secure way to solve the problem
            finally.

            Peer


            --
            Heinlein Support GmbH
            Schwedter Str. 8/9b, 10119 Berlin

            http://www.heinlein-support.de

            Tel: 030 / 405051-42
            Fax: 030 / 405051-19

            Zwangsangaben lt. §35a GmbHG: HRB 93818 B / Amtsgericht
            Berlin-Charlottenburg,
            Geschäftsführer: Peer Heinlein -- Sitz: Berlin
          • Viktor Dukhovni
            ... Thanks, this is very useful. So the Postfix work-around for servers that want to receive email over TLS from the broken Debian systems is: # cd
            Message 5 of 10 , Sep 3, 2013
            • 0 Attachment
              On Tue, Sep 03, 2013 at 12:41:46PM -0700, Phil Pennock wrote:

              > Okay, I have identified the root cause. The systems that need to be
              > placated are older Debian installs, and the method should be broadly
              > compatible.
              >
              > Debian used to patch, in their build system, the value passed to
              > gnutls_dh_set_prime_bits() from 1024 to 2048. This is the value of the
              > size of the DH parameters which is the "minimum considered acceptable".
              > So Debian broke interop with "66_enlarge-dh-parameters-size.dpatch".

              Thanks, this is very useful. So the Postfix work-around for servers
              that want to receive email over TLS from the broken Debian systems is:

              # cd /etc/postfix
              # openssl dhparam -out dh2048.pem 2048
              # postconf -e 'smtpd_tls_dh1024_param_file = ${config_directory}/dh2048.pem'

              If your openssl(1) version is 1.0.0 or higher, your server may
              perform faster if you generate DSA-style parameters:

              # openssl dhparam -dsaparam -out dh2048.pem 2048

              The "smtpd_tls_dh1024_param_file" is in effect the DH parameter
              set for all non-export cipher-suites. It is OK to use a 2048-bit
              prime group in this context, provided the CPU cost is acceptable
              (generally TLS handshake CPU cost is not on the critical path for
              SMTP throughput) and no SMTP clients choke on the larger DH prime.

              No changes should be necessary for the default Postfix EECDH curve,
              it is strong enough to meet the default lower bounds for GnuTLS,
              and Debian likely did not patch this value (in GnuTLS rather than Exim).

              Only the "Ultra" priority String in GnuTLS requires EC curves with
              more than 256-bits:

              {
              "Ultra", /* Name */
              GNUTLS_SEC_PARAM_ULTRA, /* Enum */
              256, /* Symmetric bits */
              15424, /* RSA/EDH modulus bits */
              3072, /* DSA bits */
              512, /* subgroup bits */
              512 /* EC bits */
              },

              We can reasonably assume that no MTA is configured to use the
              "Ultra" security level as a default for all Internet destinations.

              --
              Viktor.
            Your message has been successfully submitted and would be delivered to recipients shortly.