Elliptic Curve Cryptography (ECC) Cipher Suites for Transport Layer Security (TLS) Versions 1.2 and Earlier
obsoletes
- rfc-4492 — Elliptic Curve Cryptography (ECC) Cipher Suites for Transport Layer Security (TLS)
updated by
- rfc-8996 — Deprecating TLS 1.0 and TLS 1.1
Extracted elements (27)
The 'Intrinsic' (value 8) HashAlgorithm is introduced as a dummy value so that pure EdDSA (which does not pre-hash externally) can be represented in the TLS 1.2 signature_algorithms extension using the same encoding as TLS 1.3, enabling wire-format compatibility across versions.
The restriction from prior TLS versions requiring signature algorithms to match throughout a certificate chain is lifted in RFC 8422, consistent with the approach taken in RFC 5246. This allows more flexible PKI deployments without loss of security.
This specification deprecates all elliptic curves numbered 1–22 in the NamedCurve registry (from RFC 4492) as well as explicit curve formats, because only secp256r1, secp384r1, and secp521r1 had seen significant use. X25519 and X448 are added from RFC 7748 as modern, well-analyzed alternatives.
If a ClientHello omits the Supported Point Formats Extension, servers MUST treat this as equivalent to an extension allowing only the uncompressed format (per RFC 4492 behavior). Session resumption causes servers to ignore these extensions entirely; they only apply during new session negotiation.
The ECDH_anon key exchange, despite the non-'E' prefix in its name, uses ephemeral keys just like ECDHE_RSA and ECDHE_ECDSA; the naming convention follows DH_anon from earlier TLS and does not reflect the ephemeral nature of the keys.
A TLS client that proposes ECC cipher suites SHOULD include the Supported Elliptic Curves Extension and Supported Point Formats Extension. Servers implementing ECC cipher suites MUST support these extensions and MUST NOT negotiate an ECC cipher suite unless the handshake can complete while respecting the client's stated curve choices.
All ECDH calculations for NIST curves use the ECKAS-DH1 scheme from IEEE 1363 with the identity KDF; the premaster secret is the x-coordinate of the ECDH shared secret as an octet string, and leading zeros MUST NOT be truncated. For X25519/X448, if either party computes an all-zeroes premaster secret, it MUST abort the handshake.
All ECDSA computations MUST be performed according to ANSI X9.62. A secure hash function (SHA-256, SHA-384, or SHA-512) MUST be used. All EdDSA computations MUST be performed according to RFC 8032; the context parameter for Ed448 MUST be set to the empty string.
Implementations MUST support the uncompressed point format for all supported curves and MUST NOT support other point formats for curves defined in this specification. If the client sends a point format list that does not include uncompressed (0) and has indicated support for curves in this spec, the server MUST abort with an illegal_parameter alert.
In ECDH_anon, the server's Certificate, CertificateRequest, client's Certificate, and CertificateVerify messages MUST NOT be sent. The server MUST send an ephemeral ECDH public key in ServerKeyExchange, and these parameters MUST NOT be signed.
In ECDHE_ECDSA, the server's certificate MUST contain an ECDSA- or EdDSA-capable public key, and the ServerKeyExchange parameters MUST be signed with ECDSA or EdDSA using the corresponding private key.
In ECDHE_RSA, the server's certificate MUST contain an RSA public key authorized for signing, and the ServerKeyExchange signature must be computed with the corresponding RSA private key.
With NIST curves, each party MUST validate the peer's public key from ClientKeyExchange and ServerKeyExchange by verifying that the x and y parameters satisfy the curve equation y^2 = x^3 + ax + b mod p. Failure allows attackers to recover the private key in a few requests.
X.509 certificates containing ECC public keys or signed with ECDSA MUST comply with RFC 3279. Certificates with EdDSA public keys or signatures MUST comply with RFC 8410. EdDSA keys using Ed25519 MUST use the ed25519 signature algorithm; Ed448 keys MUST use ed448. Ed25519, Ed25519ph, Ed448, and Ed448ph keys MUST NOT be used with ECDSA.
RFC 8422 defines 18 ECC cipher suites across ECDHE_ECDSA, ECDHE_RSA, and ECDH_anon families, with identifiers in the 0xC0xx range. Recommended cipher suites for server implementations are TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256, TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA, TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256, and TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA.
The ClientKeyExchange message carries a ClientECDiffieHellmanPublic struct containing ecdh_Yc, the client's ephemeral ECDH public key as an ECPoint in uncompressed format. The implicit encoding (key in certificate) is deprecated and retained only for backward compatibility.
The Supported Elliptic Curves Extension (type 10) carries a NamedCurveList containing NamedCurve values in client-preference order. RFC 8422 deprecates curves 1–22 and explicit curves (0xFF01, 0xFF02), retaining secp256r1 (23), secp384r1 (24), secp521r1 (25), x25519 (29), and x448 (30).
Three ECC-based key exchange algorithms are defined: ECDHE_ECDSA (ephemeral ECDH with ECDSA or EdDSA signatures), ECDHE_RSA (ephemeral ECDH with RSA signatures), and ECDH_anon (anonymous ephemeral ECDH, no signatures). All use ephemeral ECDH to compute the TLS premaster secret and provide forward secrecy when ephemeral keys are freshly generated and destroyed after use.
To represent Ed25519 and Ed448 in the TLS 1.2 signature_algorithms extension, the values (8,7) and (8,8) are used respectively, where 8 denotes the new 'Intrinsic' HashAlgorithm value meaning hashing is intrinsic to the signature algorithm.
IANA assigned ed25519 (7) and ed448 (8) in the 'TLS SignatureAlgorithm' registry, and Intrinsic (8, DTLS-OK=Y) in the 'TLS HashAlgorithm' registry, for compatibility with TLS 1.3.
IANA maintains three registries renamed by this document (prepending 'TLS'): 'TLS Supported Groups' (formerly NamedCurve, policy: Specification Required), 'TLS EC Point Formats' (policy: Specification Required), and 'TLS EC Curve Types' (policy: Specification Required). x25519 (29) and x448 (30) were assigned in TLS Supported Groups.
All key exchange algorithms defined in this document provide forward secrecy, contingent on generating fresh ephemeral keys and destroying them after use. Some deprecated key exchange algorithms from RFC 4492 do not provide forward secrecy.
Elliptic curve selection is a critical security consideration. As a general principle, curves with less algebraic structure are more conservative (random curves over F_p with random p are preferred over special-form or Koblitz curves). Wide adoption of a single curve amplifies the impact of a potential cryptanalytic break of that curve.
Public key validation failure with NIST curves allows small-subgroup and invalid-curve attacks that can recover the static private key in a small number of handshakes. For X25519/X448, computing an all-zero shared secret indicates a degenerate input and requires aborting the handshake.
For NIST curves, ECPoint in uncompressed format is encoded as: a leading byte 0x04 (PointConversionForm=uncompressed), followed by X and Y coordinates each padded to the field size (32 bytes for P-256, 48 for P-384, 66 for P-521) in big-endian order. For X25519 and X448, the encoding is a 32- or 56-octet u-coordinate value per RFC 7748.
The NamedCurveList is encoded as a list of 2-byte NamedCurve identifiers: `struct { NamedCurve named_curve_list<2..2^16-1> } NamedCurveList;`. Items are ordered by client preference (most preferred first).
The ServerKeyExchange message carries ServerECDHParams containing ECParameters (curve_type=named_curve plus a NamedCurve identifier) and an ECPoint (the ephemeral public key), followed by a Signature. ECDSA signatures are DER-encoded as `Ecdsa-Sig-Value ::= SEQUENCE { r INTEGER, s INTEGER }`. EdDSA signatures are the raw octet string output of the EdDSA signing algorithm.