TLS supported groups: curves, FFDHE and ML-KEM

secp256r1

ECDHE on P-256: the key exchange RFC 8446 makes mandatory for every TLS 1.3 implementation.

secp256r1 (23) is the group a TLS 1.3 implementation MUST support (RFC 8446 §9.1), which makes it the fallback that always works. Its key share is a 65-byte uncompressed point; TLS 1.3 forbids compressed points for these curves. See P-256.

secp384r1

ECDHE on P-384, required by NSA's CNSA 1.0 suite.

secp384r1 (24) is marked Recommended by IANA and is the group of CNSA-compliant configurations. Its key share is 97 bytes. The hybrid SecP384r1MLKEM1024 pairs it with ML-KEM-1024 for CNSA 2.0 transitions. See P-384.

x25519

Elliptic-curve Diffie–Hellman on Curve25519, the default classical key exchange of TLS 1.3.

x25519 (29) is the most common TLS 1.3 key share and the classical half of X25519MLKEM768. RFC 8446 §9.1 says implementations SHOULD support it, next to the mandatory secp256r1. Shares are 32 bytes. See Curve25519.

ffdhe2048

The 2048-bit finite-field Diffie–Hellman group of RFC 7919.

RFC 7919 replaced server-chosen DHE parameters — often 1024-bit, sometimes shared among many servers and precomputable, as the Logjam attack showed — with five fixed, named groups. TLS 1.3 negotiates them through supported_groups. RFC 10015 §3 forbids FFDHE cipher suites in TLS 1.2, so these groups now matter only for TLS 1.3, where they are rarely used.

MLKEM768

ML-KEM-768 alone, without a classical component: a pure post-quantum TLS key exchange.

MLKEM768 (513) uses only the FIPS 203 KEM. If ML-KEM were broken, nothing would protect the session, which is why the web uses hybrids such as X25519MLKEM768; the pure groups target environments whose policy requires post-quantum-only algorithms.

SecP256r1MLKEM768

The hybrid of P-256 ECDHE with ML-KEM-768, for deployments that must stay with NIST-approved curves.

SecP256r1MLKEM768 (0x11EB, RFC 10024) combines a P-256 share with ML-KEM-768. Because both components are NIST-approved, it suits FIPS-validated deployments that cannot use X25519.

X25519MLKEM768

The hybrid post-quantum key exchange that browsers and major servers negotiate by default: X25519 combined with ML-KEM-768.

X25519MLKEM768 (0x11EC, RFC 10024) sends an ML-KEM-768 encapsulation key and an X25519 share in one key_share entry and concatenates the two shared secrets, so the session stays secret as long as either algorithm holds. It protects today's traffic against 'harvest now, decrypt later' attacks by future quantum computers. IANA marks it Recommended.

The ClientHello share is about 1.2 KB, which pushes the ClientHello beyond one TCP segment and has exposed middleboxes that cannot handle split ClientHellos. Earlier deployments used the pre-standard code point X25519Kyber768Draft00 (0x6399), now obsolete.