Negotiated Finite Field Diffie-Hellman Ephemeral Parameters for Transport Layer Security (TLS)
updates
Extracted elements (29)
The base of the natural logarithm (e) was chosen as the 'nothing-up-my-sleeve' number for deriving group moduli, ensuring middle bits are effectively random and ruling out any suspicion that primes were secretly selected to be weak. RFC 3526 used pi, but this document uses a distinct value to avoid reusing the same groups.
This document defines new FFDHE groups rather than reusing IKE groups (e.g., strongSwan's MODP groups) for three reasons: sharing groups across protocols increases the value to an attacker who cracks a single group; IKE groups include weak entries like MODP768; and mixing group parameters across implementations risks cross-protocol attacks.
A client that rejects a non-compatible server's custom FFDHE group MAY retry the connection omitting all FFDHE cipher suites, but SHOULD only do so after successfully verifying the server's signature over ServerDHParams to avoid being forced by an active attacker into a non-preferred cipher suite.
When a compatible peer interacts with a non-compatible peer, the mechanism is designed to have no detrimental effects. A non-compatible server will not receive the Supported Groups extension with FFDHE groups, so it proceeds with its existing behavior; a compatible server that receives no FFDHE groups MAY select a traditional DHE cipher suite or a non-FFDHE alternative.
When the ClientHello cipher suite preference order conflicts with the Supported Groups extension order (e.g., DHE ranked first but secp256r1 ranked first in Supported Groups), servers SHOULD give priority to the Supported Groups extension ordering. Clients SHOULD NOT present such contradictions.
A client that offers a group MUST be able and willing to perform a DH key exchange using that group. Advertising a group the client cannot use is prohibited.
A client that supports both ECDHE and FFDHE MUST use a single Supported Groups extension in the ClientHello to advertise all supported groups. Separate extensions for ECDHE and FFDHE groups are not permitted.
A compatible client that accepts FFDHE cipher suites using custom groups from non-compatible servers MUST reject any group with |dh_p| < 768 bits and SHOULD reject any group with |dh_p| < 1024 bits.
A compatible TLS server that receives the Supported Groups extension with FFDHE codepoints and selects an FFDHE cipher suite MUST select one of the client's offered groups. A server MUST NOT select a named FFDHE group that was not offered by the client.
Both peers MUST validate each other's public key Y (dh_Ys or dh_Yc) by ensuring 1 < Y < p−1. With a known safe-prime group this simple range check suffices, whereas an unknown group would require primality testing and subgroup checks.
If a compatible server receives a Supported Groups extension containing FFDHE groups but none are acceptable to the server, the server MUST NOT select an FFDHE cipher suite. If additionally no non-FFDHE cipher suite is acceptable, the server MUST terminate the connection with a fatal insufficient_security(71) alert.
If a non-anonymous FFDHE cipher suite is selected and the client has offered a group of comparable or greater strength than the server's public key, the server SHOULD select an FFDHE group at least as strong as the server's public key (e.g., prefer ffdhe4096 over ffdhe2048 for a 3072-bit RSA key).
New FFDHE groups added to the Supported Groups Registry MUST use a safe prime as the modulus to enable the inexpensive peer key-validation described in Section 5.1.
Upon receiving a ServerKeyExchange in an FFDHE handshake, the client MUST verify that dh_Ys is in the range 1 < dh_Ys < dh_p − 1. If dh_Ys is out of this range, the client MUST terminate the connection with a fatal handshake_failure(40) alert.
When an FFDHE cipher suite is selected and the client sends a ClientKeyExchange, the server MUST verify that 1 < dh_Yc < dh_p − 1. If dh_Yc is out of range, the server MUST terminate the connection with a fatal handshake_failure(40) alert.
The Supported Groups extension exposes additional bits of information that distinguish classes of TLS clients, enabling fingerprinting. To minimize fingerprinting, clients SHOULD support all named groups at or above their minimum security threshold. New groups SHOULD NOT be added to the registry without considering the fingerprinting cost.
All five FFDHE groups defined in Appendix A are safe primes derived from the base of the natural logarithm (e), with the high and low 64 bits set to 1 to enable efficient Montgomery or Barrett reduction. Each group has generator g = 2 and group size q = (p−1)/2.
Five named finite field Diffie-Hellman groups are defined using codepoints 256–260 in the Supported Groups Registry: ffdhe2048 (256), ffdhe3072 (257), ffdhe4096 (258), ffdhe6144 (259), and ffdhe8192 (260). All codepoints in the range 256–511 (high byte 0x01) are reserved for FFDHE groups; no FFDHE group will receive a codepoint outside this range.
Peers using a known FFDHE group may employ short exponents to improve performance while retaining the same approximate security level. Each group specifies a minimum exponent bit length: ffdhe2048 ≥ 225 bits, ffdhe3072 ≥ 275 bits, ffdhe4096 ≥ 325 bits, ffdhe6144 ≥ 375 bits, ffdhe8192 ≥ 400 bits.
The 'elliptic_curves(10)' extension is repurposed as the Supported Groups extension, and the NamedCurve enum is renamed to NamedGroup. Its semantics are expanded from elliptic curves only to any named group, including FFDHE groups. Clients MAY send this extension when either FFDHE or ECDHE cipher suites are listed in the ClientHello.
IANA renamed the 'EC Named Curve Registry' to the 'Supported Groups Registry' and extended it to include finite field groups. Values 256–511 are designated for FFDHE groups; values 508–511 are reserved for Private Use. Five entries (ffdhe2048–ffdhe8192, values 256–260) are allocated by this document, all marked DTLS-OK.
IANA renamed the 'elliptic_curves' TLS extension to 'supported_groups' in the ExtensionType Values registry, adding a reference to RFC 7919.
A malicious server can maneuver a client into selecting a premaster secret of the server's choice using a weak FFDHE group, which can then be replayed against a non-FFDHE server to bootstrap client authentication. Clients concerned about this attack (e.g., those using client certificate authentication) should reject non-negotiated FFDHE cipher suites with unverified group structure and reconnect without FFDHE cipher suites.
All FFDHE key exchange implementations should use constant-time modular-exponentiation to prevent timing attacks, especially when DHE secret keys are reused ('semi-static' keying) or shared across multiple machines in a load-balancer scenario.
Clients using TLS False Start (RFC 7918) that receive a weak FFDHE group may send data encrypted under a weak key before the Finished message is verified. Compatible clients performing a full handshake MUST NOT use the False Start modification if the server selects an FFDHE cipher suite but provides a group that is not cryptographically strong from the client's perspective.
FFDHE group strength determines session resilience against offline confidentiality attacks. For long-term confidentiality, stronger groups should be preferred. ENISA recommends at least 3072-bit groups for future systems; ffdhe3072 is intended for that use.
Forward secrecy depends on both sides promptly discarding ephemeral key material. Implementations SHOULD wipe FFDHE secret key material from memory as soon as it is no longer needed and MUST NOT store it in persistent storage. The strength of the DH group must also match the symmetric cipher to avoid shifting the adversary's attack to the weaker component.
The contents of the Supported Groups extension are covered by the TLS Finished message hash, so an active MITM that strips or modifies the extension will cause the handshake to fail. Impersonation attacks that manipulate the offered group list (upward or downward) are caught at the Finished check, preventing undetected downgrade to a weaker group.
FFDHE group moduli are derived by the formula p = 2^b − 2^(b−64) + {floor(2^(b−130) * e) + X} * 2^64 − 1, where b is the bit length and X is the smallest positive integer yielding a safe prime. This structure ensures the middle bits are effectively random while the high and low 64 bits are all 1s.