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

Diffie-Hellman parameters

Expand Messages
  • Fedor Brunner
    Hi, Please increase the size of Diffie-Hellman parameters in http://www.postfix.org/TLS_README.html You recommend 1024 bit DH parameters, but for long term
    Message 1 of 8 , Nov 17, 2013
    • 0 Attachment
      Hi,
      Please increase the size of Diffie-Hellman parameters in
      http://www.postfix.org/TLS_README.html
      You recommend 1024 bit DH parameters, but for long term protection,
      these parameters are too short.

      During ephemeral Diffie-Hellman (EDH) key exchange a temporary key is
      generated from DH parameters. This temporary key is used for encryption
      of the communication and the server public RSA key is used ONLY for
      signing of this temporary key and NOT for encryption of the
      communication. If you use DH parameters shorter than you RSA key, you
      are weakening your encryption.

      https://wiki.openssl.org/index.php/Diffie_Hellman
      https://wiki.openssl.org/index.php/Diffie-Hellman_parameters


      If you are interested in more technical information about key sizes I
      highly recommend:

      http://www.keylength.com/en/compare/

      Yearly Report on Algorithms and Keysizes (2012), D.SPA.20 Rev. 1.0,
      ICT-2007-216676 ECRYPT II, 09/2012.

      Recommendation for Key Management, Special Publication 800-57 Part 1
      Rev. 3, NIST, 07/2012
    • lists@rhsoft.net
      ... that s all fine but breaks interoperability leading in opportunistic mode which is needed on the MTA side to let clients fall back to *unencrypted*
      Message 2 of 8 , Nov 17, 2013
      • 0 Attachment
        Am 17.11.2013 23:36, schrieb Fedor Brunner:
        > Please increase the size of Diffie-Hellman parameters in
        > http://www.postfix.org/TLS_README.html
        > You recommend 1024 bit DH parameters, but for long term protection,
        > these parameters are too short.
        >
        > During ephemeral Diffie-Hellman (EDH) key exchange a temporary key is
        > generated from DH parameters. This temporary key is used for encryption
        > of the communication and the server public RSA key is used ONLY for
        > signing of this temporary key and NOT for encryption of the
        > communication. If you use DH parameters shorter than you RSA key, you
        > are weakening your encryption.
        >
        > https://wiki.openssl.org/index.php/Diffie_Hellman
        > https://wiki.openssl.org/index.php/Diffie-Hellman_parameters
        >
        >
        > If you are interested in more technical information about key sizes I
        > highly recommend:
        >
        > http://www.keylength.com/en/compare/
        >
        > Yearly Report on Algorithms and Keysizes (2012), D.SPA.20 Rev. 1.0,
        > ICT-2007-216676 ECRYPT II, 09/2012.
        >
        > Recommendation for Key Management, Special Publication 800-57 Part 1
        > Rev. 3, NIST, 07/2012

        that's all fine but breaks interoperability leading in opportunistic mode
        which is needed on the MTA side to let clients fall back to *unencrypted*
        connections - so you may consider what is better - 1024 bit or no
        encryption at all

        you can do that on a webserver but not on a MTA
      • Viktor Dukhovni
        ... Postfix prime-DH support is constrained by the limitations of the TLS protocol (which does not negotiate prime-DH bit length). Further limits are imposed
        Message 3 of 8 , Nov 17, 2013
        • 0 Attachment
          On Sun, Nov 17, 2013 at 11:36:34PM +0100, Fedor Brunner wrote:

          > Please increase the size of Diffie-Hellman parameters in
          > http://www.postfix.org/TLS_README.html
          > You recommend 1024 bit DH parameters, but for long term protection,
          > these parameters are too short.

          Postfix prime-DH support is constrained by the limitations of the
          TLS protocol (which does not negotiate prime-DH bit length).

          Further limits are imposed by the fact that various SMTP client
          implementation (mostly seen in submission MUAs) don't support bit
          lengths over 1024, and will fail to connect to servers with larger
          DH primes.

          On the other hand, some Exim MTA SMTP clients (patched by a
          well-meaning, but under-informed Debian maintainer) don't support
          DH primes shorter than 2048 bits. While Debian have since corrected
          the erroneous Exim client-side DH prime lower-bound, not all the
          users of the non-interoperable Exim have deployed updates that
          resolve the issue.

          Keep in mind that today (with almost zero installed base for DANE)
          almost all MTA to MTA SMTP traffic is unencrypted, and even the
          10-20% of traffic that does use TLS is opportunistic. Setting DH
          parameters to comply with strict limits can be counter-productive,
          as after TLS session setup fails, MTAs will generally fallback to
          plaintext.

          This said, it has been found that MTAs that are TLS capable,
          generally support 2048-bit DH primes. Thus it is possible
          to configure Postfix as follows:

          Once as root:
          # cd /etc/postfix
          # openssl dhparam -out dh2048.pem 2048
          # openssl dhparam -out dh1024.pem 1024
          # openssl dhparam -out dh512.pem 512

          main.cf:
          # MTAs are generally able to support 2048-bit EDH as clients.
          smtpd_tls_dh1024_param_file = ${config_directory}/dh2048.pem
          smtpd_tls_dh512_param_file = ${config_directory}/dh512.pem

          with master.cf overrides:

          -o smtpd_tls_dh1024_param_file=${config_directory}/dh1024.pem

          for any submission services that need to support clients (phones,
          ipads, ...) that may not be able to do 2048-bit EDH.

          The above works at sites where subission is on port 587 only, and
          port 25 is only for MTA to MTA traffic.

          If you are sufficiently motivated, a patch for proto/TLS_README.html
          that explans the above would be appreciated.

          --
          Viktor.
        • Andreas Schulze
          ... I had trouble to receive messages from those sites too. I changed smtpd_tls_dh1024_param_file to use a 2k dh key at the mx server. That solved the problem
          Message 4 of 8 , Nov 18, 2013
          • 0 Attachment
            Zitat von Viktor Dukhovni <postfix-users@...>:

            > On the other hand, some Exim MTA SMTP clients (patched by a
            > well-meaning, but under-informed Debian maintainer) don't support
            > DH primes shorter than 2048 bits.

            I had trouble to receive messages from those sites too.

            I changed smtpd_tls_dh1024_param_file to use a 2k dh key at the mx server.
            That solved the problem ...

            Andreas
          • Viktor Dukhovni
            ... Any evidence of other legitimate MTAs that now routinely fail TLS handshakes? I don t believe that the rather minimal TLS stack on Windows 2003 supports
            Message 5 of 8 , Nov 18, 2013
            • 0 Attachment
              On Mon, Nov 18, 2013 at 10:53:19AM +0100, Andreas Schulze wrote:

              > >On the other hand, some Exim MTA SMTP clients (patched by a
              > >well-meaning, but under-informed Debian maintainer) don't support
              > >DH primes shorter than 2048 bits.
              >
              > I had trouble to receive messages from those sites too.
              >
              > I changed smtpd_tls_dh1024_param_file to use a 2k dh key at the mx server.
              > That solved the problem ...

              Any evidence of other legitimate MTAs that now routinely fail TLS
              handshakes?

              I don't believe that the rather minimal TLS stack on Windows 2003
              supports any EDH ciphersuites, so old Microsoft Exchange versions
              are probably unaffected.

              Similarly, no MTAs using OpenSSL or GnuTLS have such a limit, thus
              Sendmail, Exim and Qmail patched with TLS support are fine.

              The historical upper-bound on prime-DH sizes in NSS (the PKI stack
              in Netscape and then Firefox, ...) is 2236 bits. Thus 2048-bits
              should interoperate with Oracle Communications Messaging Server.

              https://bugzilla.mozilla.org/show_bug.cgi?id=636802

              This leaves email from the large consumer email providers (Gmail,
              Hotmail, Yahoo, AOL), various vendor border SMTP appliances and
              various telco ISP email systems.

              Is there any evidence of inbound TLS handshake failures from any
              MTAs in the last group that is possibly related to interoperability
              issues with 2048 bit EDH?

              --
              Viktor.
            • Andreas Schulze
              ... no, I don t saw more TLS errors. There is a usual noise of TLS failures that didn t changed. Andreas
              Message 6 of 8 , Nov 18, 2013
              • 0 Attachment
                Zitat von Viktor Dukhovni <postfix-users@...>:

                > Any evidence of other legitimate MTAs that now routinely fail TLS handshakes?
                no, I don't saw more TLS errors.
                There is a usual noise of TLS failures that didn't changed.

                Andreas
              • LuKreme
                ... I can t imagine that that didn t cause other problems. If a server negotiates for a dh1024 key and is expecting a dh1024 key and it gets a dh2048 key, it
                Message 7 of 8 , Nov 18, 2013
                • 0 Attachment
                  On 18 Nov 2013, at 02:53 , Andreas Schulze <sca@...> wrote:

                  > I changed smtpd_tls_dh1024_param_file to use a 2k dh key at the mx server.
                  > That solved the problem ...

                  I can't imagine that that didn't cause other problems. If a server negotiates for a dh1024 key and is expecting a dh1024 key and it gets a dh2048 key, it is (hopefully) going to pitch a fit and barf.

                  --
                  "I do not feel obliged to believe that same God who endowed us with
                  sense, reason, and intellect had intended for us to forego their use."
                • Viktor Dukhovni
                  ... There is no negotiation for a DH 1024 prime. TLS clients announce support for various prime-DH cipher-suites with an *unspecified* prime size. The TLS
                  Message 8 of 8 , Nov 18, 2013
                  • 0 Attachment
                    On Mon, Nov 18, 2013 at 08:03:00AM -0700, LuKreme wrote:

                    > > I changed smtpd_tls_dh1024_param_file to use a 2k dh key at the mx server.
                    > > That solved the problem ...
                    >
                    > I can't imagine that that didn't cause other problems. If a server
                    > negotiates for a dh1024 key and is expecting a dh1024 key and it
                    > gets a dh2048 key, it is (hopefully) going to pitch a fit and barf.

                    There is no negotiation for a DH 1024 prime. TLS clients announce
                    support for various prime-DH cipher-suites with an *unspecified*
                    prime size. The TLS server announces the prime unilaterally in
                    its Server Key Exchange message when it chooses such a cipher-suite
                    from the client's list.

                    Based on TLS protocol standards alone, all primes are equal, but
                    clearly some primes are more equal than others. Some clients want
                    primes that are not too large, others primes that are not too small.
                    So the server needs a "Goldilocks prime". :-)

                    The bit-length of a "Goldilocks prime" varies by application
                    protocol, based on the capabilities of the client implementations
                    of that application protocol. For MTA to MTA SMTP, we have some
                    evidence that 2048-bits is "just right", for MUA to MTA submission,
                    1024-bits is for now more appropriate.

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