<b>What actually changed in the structure of a TLS 1.3 cipher suite name?</b>

<b>What actually changed in the structure of a TLS 1.3 cipher suite name?</b>

The rename is small on screen but reflects a deep redesign worth reading precisely.

A TLS 1.2 suite like ECDHE-RSA-AES128-GCM-SHA256 encodes four independent choices: key exchange (ECDHE), authentication (RSA), bulk cipher (AES-128-GCM), and the hash for the pseudo-random function (SHA-256). The suite negotiated all four together.

TLS 1.3 (RFC 8446) decouples them. Key exchange and authentication are negotiated separately — via supported_groups, key_share, and signature_algorithms — so they no longer belong in the suite name. What remains is the AEAD cipher plus the HKDF hash. Hence the entire TLS 1.3 suite registry is tiny: TLS_AES_128_GCM_SHA256, TLS_AES_256_GCM_SHA384, TLS_CHACHA20_POLY1305_SHA256, plus two CCM variants.

The word AEAD (Authenticated Encryption with Associated Data, RFC 5116) is the crux. TLS 1.3 mandates AEAD and removed every non-AEAD construction. The old MAC-then-encrypt and CBC-mode suites that enabled Lucky 13, BEAST, and POODLE-class padding-oracle attacks are simply not expressible. There is no RC4, no CBC, no static-RSA key exchange, no compression.

This is why TLS 1.3 has far fewer suites: the insecure combinatorial space was deleted, not merely deprecated.

Further reading: RFC 8446 §B.4, RFC 5116, RFC 7905 (ChaCha20-Poly1305).

Bottom line: a TLS 1.3 suite names only the AEAD cipher and hash because authentication and key exchange moved to their own extensions — and every padding-oracle-prone mode was removed outright.