Explicitly configure curves/groups from the guidelines

[janbrasna]

In the past this was part of the configs, only allowing curves enumerated in the json data for the configs. At some point it got removed due to bugs in implementations, and also clients and servers being able to negotiate the reasonable thing anyways.

History

The original issue #44 when lighttpd wouldn't support multiple values is hopefully just a thing of the past. The support in nginx template was removed (or not added at all) due to reasons described in #76 (for details see https://trac.nginx.org/nginx/ticket/1089 — e.g. this needs #141 resolved first).

Background

If we want to officially support OpenSSL 3.x in #260, the issue with performance #162 is relevant again, this time even for modern (and way past any TLSv1.2 DHE suites removal from the lists) — as OpenSSL 3.x started supporting FFDH key exchange for TLSv1.3 — which is part of RFC 8446 requiring RFC 7919, allowing to negotiate unnecessarily large keys (see https://openssl-library.org/post/2022-10-21-tls-groups-configuration/ for mitigation recommendations from the authors).

See the overview at https://datatracker.ietf.org/doc/html/rfc7919#section-2 for addition of groups to curves, and their codepoints.

This wasn't an issue with OpenSSL 1.x.x as it only had support for ECDH key exchange in TLSv1.3, so we didn't have to restrict anything really. That changes with OpenSSL 3.x adding support for FFDH in TLSv1.3 (and others, too: see https://dheatattack.gitlab.io/mitigations/#tls for e.g. GnuTLS versions.)

BTW for the future of OpenSSL 3.x support for RFC 7919 also in TLSv1.2 follow:

• Add support for named ffdhe groups in TLSv1.2 (RFC7919) openssl/openssl#10971
• Enable RFC 7919 FFDHE groups for TLS 1.2 server openssl/openssl#24551

Actions

To officially extend the support to the current OpenSSL versions that now allow (and enable by default without any group restriction) FFDH too, and keep the same guidelines, we have to consider either explicitly restricting the RFC 7919 groups to a reasonable subset (as some servers already do), or decide on not allowing any FFDH key exchange to begin with, and resort back to just recommending EC curves (as we currently do, just neither explain it, not enforce it though).

This may need revisiting all the "curves" settings in servers, whether they mean any RFC 7919 groups by that (as most would probably silently do), or if they separate ECDH and FFDH settings and configure both independently (as some do, with good defaults FWIW) — to give us a better idea of how such approach is feasible, and whether we'll be able to limit or completely restrict the groups allowed.

[polarathene]

Just for context, 2048-bit modulus for DHE / RSA is fine (more than that is effectively wasted compute + network resources): #256 (comment)

Some may need to bump that to 3072-bit for compliance reasons beyond their control despite that. That's the only valid reason that comes to mind, beyond some flaw in the math side being discovered that weakens the security 😅

[janbrasna]

I'd err on the side of not even enabling ffdhe* groups to match the performance from 1.1.1 — to continue setting ffdhe2048 params for TLSv1.2, and only EC curves for TLSv1.3 — that would also mean no impact to the guidelines thus no need for a new release, just some minor wording tweaks.

But wanted to open this for broader discussion before making any decisions.