AES Galois Counter Mode (GCM) Cipher Suites for TLS
updated by
- rfc-9325 — Recommendations for Secure Use of Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS)
Extracted elements (15)
AES-GCM was chosen as an AEAD cipher for TLS because it provides both confidentiality and data origin authentication in a single pass, can be pipelined in hardware to achieve 10 Gbps and above, and is also efficient in software implementations.
The nonce structure uses a 'partially explicit' design (per RFC 5116 Section 3.2.1): the 4-byte salt is implicit (derived from the handshake key material) and not transmitted, while the 8-byte nonce_explicit is sender-chosen and carried in each record, balancing bandwidth efficiency with uniqueness guarantees.
ECC-based AES-GCM cipher suites are explicitly out of scope for this document and are defined separately in RFC 5289.
The truncated_hmac TLS extension (RFC 4366 Section 3.5) has no effect on these cipher suites because they do not use HMAC; all suites use a 128-bit GCM authentication tag regardless.
Clients MUST check the TLS version and generate a fatal 'illegal_parameter' alert if they detect an incorrect version (e.g., a non-compliant server negotiating TLS 1.1 or earlier with one of these suites).
Each value of the nonce_explicit MUST be distinct for each distinct invocation of the GCM encrypt function for any fixed key; failure to meet this uniqueness requirement can significantly degrade security.
For cipher suites ending with _SHA256, the PRF SHALL be the TLS PRF with SHA-256; for those ending with _SHA384, the PRF SHALL use SHA-384.
Implementations MUST send TLS Alert bad_record_mac for all types of failures encountered in processing the AES-GCM algorithm.
These cipher suites MUST NOT be negotiated in older versions of TLS; clients MUST NOT offer them if they do not offer TLS 1.2 or later, and servers that select an earlier version MUST NOT select one of these cipher suites.
When multiple encryption processors are used, the FixedDistinct fields used by different processors MUST have the same length to ensure uniform nonce structure.
Twelve cipher suites are defined using AES-GCM with RSA, DHE_RSA, DH_RSA, DHE_DSS, DH_DSS, and DH_anon key exchanges, covering both 128-bit and 256-bit AES key sizes, assigned codepoints 0x009C through 0x00A7.
IANA assigned codepoints for 12 new TLS cipher suites: TLS_RSA_WITH_AES_128_GCM_SHA256 (0x00,0x9C) through TLS_DH_anon_WITH_AES_256_GCM_SHA384 (0x00,0xA7) in the TLS Cipher Suite registry.
AES-GCM security requires that the counter is never reused; the IV construction in Section 3 (combining a per-handshake salt with a per-record nonce_explicit) is specifically designed to prevent counter reuse.
When multiple encryption processors share a key, the sender MUST ensure each nonce_explicit value is distinct across processors; each processor SHOULD embed a fixed distinct sub-field (FixedDistinct) with uniform length, combined with a per-record variable counter.
The GCM nonce is 12 bytes total, composed of a 4-byte implicit salt (client_write_IV or server_write_IV, not transmitted) concatenated with an 8-byte explicit nonce_explicit carried in each TLS record in GenericAEADCipher.nonce_explicit.