[gnutls-devel] GnuTLS | DH RFC7919 negotiation not enabled automatically (#1077)

[Read-only notification of GnuTLS library development activities]

Andreas Metzler created an issue: https://gitlab.com/gnutls/gnutls/-/issues/1077



## Description of problem:

Docs for gnutls_certificate_set_dh_params() say:
~~~
gnutls_certificate_set_dh_params is deprecated and should not be used in
newly-written code.

This function is unnecessary and discouraged on GnuTLS 3.6.0 or later.
Since 3.6.0, DH parameters are negotiated following RFC7919.
~~~

Which I would read as "when upgrading code to (only) work with gnutls 3.6.0 one should delete any gnutls_certificate_set_dh_params()-invocations since they are unnecessary because GnuTLS will automatically do RFC7919 negotiation."

However it looks like (see below) that is not true, there is no automation but gnutls_certificate_set_dh_params needs to be replaced with gnutls_certificate_set_known_dh_params ().

## Version of gnutls used:
3.6.14

## Distributor of gnutls (e.g., Ubuntu, Fedora, RHEL)
Debian

## How reproducible:
always

Steps to Reproduce:

Take ex-serv-x509 and remove
gnutls_certificate_set_known_dh_params(x509_cred, GNUTLS_SEC_PARAM_MEDIUM);

After this change
> openssl s_client -connect localhost:5556  -cipher DHE-RSA-AES256-GCM-SHA384-tls1_2
will fail.

This originally came up in https://github.com/rbsec/sslscan/issues/214
https://bugs.debian.org/968145 (Exim: no TLS1.2 DHE ciphers from openssl client). I have asked first on gnutls-help list, where Daiki Ueno responded with
~~~
That was also my expectation, though I suspect that it's saying that it
only works when the client advertises the "supported_groups" extension
according to the RFC, which is not sent with the above command.

In the OpenSSL git master, s_client provides the -groups option for
that, and you will be able to connect to the server with:

  $ openssl s_client -connect localhost:5556 -tls1_3 -groups ffdhe2048

though the option doesn't seem to work with -tls1_2
~~~

I think this qualifies as a bug, the documentation does not clearly describe the actual behavior. While it could be fixed by updating the docs I would prefer to fix the behavior instead, since third party software (exim) has been coded to match the docs.

-- 
Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/issues/1077
You're receiving this email because of your account on gitlab.com.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.gnupg.org/pipermail/gnutls-devel/attachments/20200829/f8748d1f/attachment.html>