Default DHE group

[Matt Caswell]

On 18/03/2019 23:05, Zeev Tarantov wrote:
> Since openssl verion 1.1.0, code for TLS server can use
> `SSL_CTX_set_dh_auto(ctx, 1);` to let openssl handle choice of DH group which
> will be used to generate ephemeral keys if a DHE cipher suite is negotiated.
> 
> TLS 1.3 limits DHE parameters to use groups from RFC 7919, from ffdhe2048 to
> ffdhe8192.
> Reference: https://tools.ietf.org/html/rfc8446#section-4.2.8.1
> 
> I'm looking at the function ssl_get_auto_dh in github master and you get one of:
> RFC 5114 DH_get_1024_160
> RFC 5114 DH_get_2048_224
> RFC 3526 BN_get_rfc3526_prime_3072
> RFC 3526 BN_get_rfc3526_prime_8192
> 
> Because SSL_CTX_set_dh_auto does not use the values from RFC 7919, application
> developers choose to not use SSL_CTX_set_dh_auto.
> See for example this commit to nginx web server:
> https://hg.nginx.org/nginx/rev/1aa9650a8154

Well I don't think that commit is an example of developers choosing not to use
SSL_CTX_set_dh_auto because it doesn't use the values from RFC7919. The commit
doesn't mention RFC7919 at all and actually predates the publication of that RFC
in any case. Rather it seems to be a policy decision to not use fixed DH
parameters due to precomputation attacks. That concern would apply equally well
to RFC7919 - although I'm not aware of any practical precomputation attacks for
non-export grade DH params.

I'm also not aware of any concerns raised about the RFC3526/RFC5114 params
(other than the 1024 one is quite small - but looking at the logic of
SSL_CTX_set_dh_auto it selects a size based on the strength of the other
elements in the ciphersuite - so it will use larger DH params where appropriate).

> I also cannot really recommend postfix switch to SSL_CTX_set_dh_auto from the
> hardcoded default generated by the postfix developers
> (https://github.com/vdukhovni/postfix/blob/postfix-3.4/postfix/src/tls/tls_dh.c).
> 
> Patching software using openssl to use RFC 7919 groups "manually" does not scale
> well. Expecting server admins to configure this at install time is laughable.
> 
> The situation is so dire, Google Chrome famously decided there are so many
> RSA-2048/DHE-1024 web servers deployed, that disabling DHE is the right thing to do!

Again, this seems to be mixing up different things. I'm not sure how that is
relevant to the RFC7919 vs RFC5114/RFC3526 discussion.

> 
> In case dh_auto was set, why doesn't openssl use the RFC 7919 groups also with
> TLS versions below 1.3?

In fact OpenSSL does not support DHE in TLSv1.3 at all so it is not a case of
using RFC7919 for one protocol version and not for others. There is a PR for
adding TLSv1.3 support for this:

https://github.com/openssl/openssl/pull/8178

The reason that they aren't supported by SSL_CTX_set_dh_auto() at the moment is
that that function was introduced before RFC7919 was published (and in fact
1.1.0 was released in the same month as the publication of that RFC). I notice
that the underlying RFC7919 params have been integrated into the latest versions
of OpenSSL but only in libcrypto - not in libssl. I'd certainly have no
objection to updating SSL_CTX_set_dh_auto() to use more modern parameters in
OpenSSL 3.0 (PRs welcome) - although I don't think we could justify backporting
such a change to a stable branch (1.1.1).

Matt