Diffie-Hellman parameters

[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 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

[l***@rhsoft.net]

Post by 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
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]

Post by 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.

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.

[Andreas Schulze]

Post by Viktor Dukhovni
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]

Post by Andreas Schulze

Post by Viktor Dukhovni
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?

[Andreas Schulze]

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]

Post by Andreas Schulze
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.

[Viktor Dukhovni]

Post by LuKreme

Post by Andreas Schulze
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.