Which Diffie-Hellman Groups does TLS 1.3 support? And should we use TLS 1.3 as a guide?

Question

This is a two part question - and I'm asking as someone moving into a security role, who'll need to standardize practices going forward.

(1) I'm curious whether the following 10 different DH Groups are the only groups that TLS 1.3 supports, (2) and as such, are they the only ones that we should be using?

https://www.rfc-editor.org/rfc/rfc8446#section-4.2.7

      /* Elliptic Curve Groups (ECDHE) */
      secp256r1(0x0017), secp384r1(0x0018), secp521r1(0x0019),
      x25519(0x001D), x448(0x001E),

      /* Finite Field Groups (DHE) */
      ffdhe2048(0x0100), ffdhe3072(0x0101), ffdhe4096(0x0102),
      ffdhe6144(0x0103), ffdhe8192(0x0104),

Some discussion into what curves should be used has already taken place here, which mentions that secp256r1 and secp384r1 are best.

---

I've read over the RFCs and this post and understand that there are only 5 ciphersuites that TLS 1.3 supports, 3 of which are mandated for compliance with the standard (there are also 3 mandated Signature Algorithms). I also understand that the Signature Algorithms and the Supported Groups are communicated in other Extensions

(2) To elaborate on my second query: Given that TLS 1.3 was developed over years by experts, and that it only supports certain cypher mechanisms - can we take that to mean that these are the only mechanisms that should be used?

Basically, should we configure any TLS 1.1 and TLS 1.2 connections (web servers, SSL-VPN servers and IKE/IPSEC tunnels) to use/prefer the mechanisms listed in the TLS 1.3 RFC if the software/hardware supports it?

Answer 1

(1) I'm curious whether the following 10 different DH Groups are the only groups that TLS 1.3 supports,

Yes, in the sense that TLS 1.3 only allows groups that are explicitly declared as supported in 1.3. This currently includes not only the groups from RFC 8446, but possibly more recent RFC as well, such as Brainpool curves from RFC 8734.

The TLS supported groups registry lists all the groups, but unfortunately it doesn't distinguish between protocol versions (you have to chase this information down in the RFC given as references). The “recommended” column is specifically about TLS 1.3, but it is neither a minimum supported set nor a maximum safe set (you can have good interoperability even without the full “recommended” set, and the non-recommended set includes both acceptable things such as FFDH and bad things such as 160-bit elliptic curves).

(2) and as such, are they the only ones that we should be using?

You certainly shouldn't be using other groups in TLS 1.3 since they wouldn't comply with the protocol. Your software isn't likely to support other groups in TLS 1.3 anyway.

(2) To elaborate on my second query: Given that TLS 1.3 was developed over years by experts, and that it only supports certain cypher mechanisms - can we take that to mean that these are the only mechanisms that should be used?

No: it's ok to use other mechanisms in older versions of the protocol. Not every mechanism that is safe to use made it into TLS 1.3. Some mechanisms that are safe but don't have any practical advantage (faster, smaller code, smaller message size, etc.) didn't make it into TLS 1.3. One of the goals of TLS 1.3 was to reduce the complexity of the protocol, which means fewer choices.

With TLS ≤1.2, you need to balance security (as in: risk of implementation bugs, known protocol weaknesses, or yet undiscovered protocol weaknesses) with interoperability. (This is true with TLS 1.3 as well, but 1.3 hasn't been along for long enough to have interoperability problems when it goes through at all.) Due to the number of existing options and the diversity of the existing software, there's no single right answer for where to put the balance.

Some discussion into what curves should be used has already taken place here, which mentions that secp256r1 and secp384r1 are best.

That discussion was in the context of TLS 1.2, which didn't support the same curves. There's no reason to reject any of the curves supported in TLS 1.3 except maybe secp521r1, which is susceptible to implementation weaknesses. (As the name hints, secp521r1 involves 521-bit numbers – and yes, it's 521 and not 512. Because this is slightly larger than a multiple of 64, there's a non-negligible chance that certain intermediate numbers will have the most significant word be 0, and insufficiently protected implementations might leak that fact when the number is multiplied because the multiplication will be slightly faster. This leak can be enough to allow an attacker to reconstruct the private key with a moderate number of connection attempts.) Curve25519 is perfectly fine and arguably preferable to secp curves because it's easier to implement securely. Back in 2015 it was not commonly supported in TLS, but in 2021 it's a standard part of TLS 1.3. Curve448 is slower and has no particular advantage (barring yet unkown weaknesses in other curves), but it's ok to use it.

For finite-field Diffie Hellman, don't use groups smaller than 2048 bits. Older versions of TLS allow custom groups, and there's no consensus on whether to make use of that. On the one hand, using standard groups might allow an attacker with sufficient computing power (read: NSA) to precompute a very large number of values which then makes attacks feasible. On the other hand, generating good custom groups is slow and hard, and doing that risks creating vulnerabilities that are easier to exploit, such as letting a man-in-the-middle persuade the participants to use a weak group. This is why TLS 1.3 mandates the use of known good groups.

Answer 2

Yes, those are the 5 Elliptic Curves groups that are currently supported for ECDHE and 5 Finite fields for DHE.

If you want compliance with the TLS 1.3 standard, those are the only ones.

DHE is losing its ground to the ECC version since ECC is faster. If you insist to use DHE, use a field size larger than 2048.

one discussion into what curves should be used has already taken place here, which mentions that secp256r1 and secp384r1 are best.

Not exactly, there are various factors for the security, let's look at the safecurves:

• Curve-P 384 = secp384r1
• Curve-P-256 = secp256r1

Curve	Safe	field	eqn	base	rho	tranr	disc	rigid	ladder	twist	complete	ind
NIST P-256	F	T	T	T	T	T	T	F	F	T	F	F
NIST P-384	F	T	T	T	T	T	T	F	F	T	F	F
Curve25519	T	T	T	T	T	T	T	T	T	T	T	T
Ed448-Goldilocks	T	T	T	T	T	T	T	T	T	T	T	T

I would go for Curve25519, however, if you are communicating or producing a product for the USA government you must go for the NIST curves. There is a slide from Bernstein and Lange about the problems with the NIST curves. x448 is overkill since as long as there is no huge breakthrough in DLog or any other new attacks, Curve25519 has exactly 128-bit security even in batch attacks. The only foreseeable attack is the Quantum that breaks both Curve25519 and x448, and others.

The choice really depends on your target application. For example, for bitcoin secp256k1, the missing points are not a real problem.

(2) To elaborate on my second query: Given that TLS 1.3 was developed over years by experts, and that it only supports certain cipher mechanisms - can we take that to mean that these are the only mechanisms that should be used?

According to a new attack and founding, all can be changed. For example, Google and Cloudflare started to test a post-quantum KEMTLS that is a Key Exchange Mechanism that resists Quantum attacks.

There is also a new working on IETF Hybrid key exchange in TLS 1.3 and the current standard may not enough to handle the required key sized of the post-quantum key exchanges. The TLS 1.3's key_exchange field limited to 2^16-1 bytes, which is very high for traditional KEM's, this turns that it cannot support even round 2 Post Quantum Key Exchange candidate's key sizes. For example, the Classic McEliece's smallest parameter set has a public key size of 261120 bytes. Nees to resolve.

Basically, should we configure any TLS 1.1 and TLS 1.2 connections (web servers, SSL-VPN servers and IKE/IPSEC tunnels) to use/prefer the mechanisms listed in the TLS 1.3 RFC if the software/hardware supports it?

Stick to TLS 1.3 only whenever possible. There are tons of downgrade based attacks on TLS if you support both. First, downgrade; then use the attacks on the TLS 1.2.

Answer 3

You can see the list of all supported groups at the IANA, which tracks all of the assigned code points. There are many more items than are listed, although they aren't available in TLS 1.3.

In general, what you should use depends on (a) what security level you want to have, (b) what your software and hardware support, and (c) what your performance requirements are. While there are other algorithms that are secure, picking only algorithms that are in TLS 1.3 is a prudent course of action.

If you're looking for a 128-bit security level, then anything in the TLS 1.3 list should be sufficient except ffdhe2048. If you're looking for a 192-bit security level, then you'll need ffdhe8192, x448, secp384r1, or secp521r1. Note that in some implementations, while secp256r1, x25519, and x448 are constant time, secp384r1 and secp521r1 are not, so you should make sure that your implementation only configures elliptic curves that are implemented in a constant-time manner. This is the main reason I prefer the non-NIST curves: because they're easier to implement in a constant-time way and as a result almost always are.

In general, elliptic curves give you much better performance for the security level, so if you can standardize on those, that may be desirable.

The reason that TLS 1.3 only supports AEADs is because the non-AEAD algorithms in TLS were MAC-then-Encrypt, not Encrypt-then-MAC. That means that you have to implement padding verification and MAC checking as one giant constant-time operation and it's hard to do. If you're using a protocol where you have Encrypt-then-MAC, then there's no reason that you can't use a combined mode like CTR and HMAC. However, having said that, you can very well standardize on AEADs alone. That is definitely a lot easier to explain to folks as a company policy.

Which algorithms you want to use depends on what hardware you're using. If you're using x86-64 hardware, it will usually have AES and PCLMULQDQ extensions which makes AES-GCM fast and secure. If you're working with embedded devices, AES and/or GCM may not be implemented in a constant-time way, or may not be very performant, and ChaCha20-Poly1305 is preferable. It is, of course, fine to use AES-CCM, which is good for machines that have hardware AES but not hardware polynomial multiplication, but you should avoid the short-tag forms. You can also use AES256-CCM if your environment supports it, even if TLS 1.3 does not.