skip to content

Why does the TLS 1.3 specification define only five cipher suites, and what left the suite string?

level: middleimportance: must knowfreq 58%

answer

  1. orthogonal decisions left the token
  2. only AEAD plus derivation hash remain
  3. groups and signatures moved to extensions
  4. five entries, code points 0x1301 to 0x1305
  5. one MUST, two SHOULD, two merely defined

basics

~20 s

A TLS 1.3 suite names only an AEAD algorithm and the hash used for key derivation. Key exchange moved to supported_groups(10) and key_share(51), and authentication to signature_algorithms(13), so the combinatorial explosion that produced dozens of TLS 1.2 suites disappeared.

solid answer

~40 s

In TLS 1.2 one token named four choices, so every combination of exchange, authentication, cipher and hash needed its own registered code point — which is why the registry runs to dozens of entries. TLS 1.3 split those decisions up: the group is negotiated in `supported_groups(10)` with the share in `key_share(51)`, the server's signature in `signature_algorithms(13)`, and the suite is left naming just the **AEAD algorithm plus the hash used with `HKDF-Expand-Label`** for key derivation and the transcript. Five combinations cover it: `TLS_AES_128_GCM_SHA256 {0x13,0x01}`, `TLS_AES_256_GCM_SHA384 {0x13,0x02}`, `TLS_CHACHA20_POLY1305_SHA256 {0x13,0x03}`, `TLS_AES_128_CCM_SHA256 {0x13,0x04}` and `TLS_AES_128_CCM_8_SHA256 {0x13,0x05}`. A conforming implementation MUST implement the first and SHOULD implement the second and third.

code

json · 9 lines
json
{
  "tls13_cipher_suites": [
    { "name": "TLS_AES_128_GCM_SHA256",       "value": "{0x13,0x01}", "status": "MUST implement" },
    { "name": "TLS_AES_256_GCM_SHA384",       "value": "{0x13,0x02}", "status": "SHOULD implement" },
    { "name": "TLS_CHACHA20_POLY1305_SHA256", "value": "{0x13,0x03}", "status": "SHOULD implement" },
    { "name": "TLS_AES_128_CCM_SHA256",       "value": "{0x13,0x04}", "status": "defined" },
    { "name": "TLS_AES_128_CCM_8_SHA256",     "value": "{0x13,0x05}", "status": "defined, 8-octet tag" }
  ]
}

go deeper

for a junior

Recall that a TLS 1.3 suite names an authenticated cipher and a hash, and that the list is short. Being able to name TLS_AES_128_GCM_SHA256 as the one every implementation must have is enough at this level.

for a middle

Explain the combinatorial argument: four orthogonal choices in one token needed one code point per combination, and splitting them into extensions collapsed the space. Name which extension took which decision.

for a senior

Show that you audit the group and signature policy separately, because the suite list no longer covers them, and quote the MUST and SHOULD strengths accurately rather than flattening them into one requirement.

for a principal

Treat the split as a design lesson about negotiation surfaces: orthogonal parameters negotiated independently shrink a registry, but they also multiply the places a policy must be written and later reviewed.

## What a TLS 1.3 suite still names In TLS 1.3 (`RFC 8446`) a cipher suite is a much smaller object than its 1.2 ancestor. It names exactly **two** things: 1. the **AEAD algorithm** that protects every record after the handshake, and 2. the **hash** used with `HKDF-Expand-Label` and `Derive-Secret` for key derivation, and used for the handshake transcript. That is all. The token still looks like the old one — `TLS_`, then algorithms separated by underscores — but there is no key-exchange element and no authentication element in it any more. ## The five suites the specification defines | Name | Code point | Status in RFC 8446 | |---|---|---| | `TLS_AES_128_GCM_SHA256` | `{0x13,0x01}` | MUST implement | | `TLS_AES_256_GCM_SHA384` | `{0x13,0x02}` | SHOULD implement | | `TLS_CHACHA20_POLY1305_SHA256` | `{0x13,0x03}` | SHOULD implement | | `TLS_AES_128_CCM_SHA256` | `{0x13,0x04}` | defined, neither required nor recommended | | `TLS_AES_128_CCM_8_SHA256` | `{0x13,0x05}` | defined, and uses a shortened 8-octet authentication tag | State the strengths exactly as the specification does: **MUST** for `TLS_AES_128_GCM_SHA256`, **SHOULD** for the AES-256-GCM and ChaCha20-Poly1305 pair, and nothing stronger for the two CCM entries. Promoting a SHOULD to a MUST in an interview answer teaches a false certainty. The list is five because that is what the specification itself defines; a small number of further 1.3-compatible suites have been registered elsewhere for regional algorithm profiles, and none of them is part of the interoperable public set. ## Where the other two decisions went - **Key exchange** is negotiated in `supported_groups(10)`, with the client's actual public share carried in `key_share(51)`. If the server wants a group the client did not send a share for, it answers with a `HelloRetryRequest` rather than picking a different suite. - **Authentication** is negotiated in `signature_algorithms(13)` — and, where the certificate chain's own signatures need separate constraint, `signature_algorithms_cert(50)`. This is the structural reason the list shrank. In 1.2 the registry had to carry one code point per *combination*: every exchange multiplied by every authentication type multiplied by every cipher multiplied by every hash. Split the orthogonal decisions into their own extensions and the suite space collapses to the number of genuinely distinct record-protection profiles — which is small, because there are only a handful of AEAD algorithms worth standardising. ## The tag length is in the name `TLS_AES_128_CCM_8_SHA256` is the one entry whose name encodes something beyond "algorithm plus hash": the trailing `_8` before the hash marks a **shortened, 8-octet authentication tag** instead of the full 16-octet tag the other CCM suite uses. That is a deliberate trade for constrained links where 8 extra octets per record matter, and it costs forgery resistance proportionally. It is the clearest illustration that a suite token can carry a parameter of the mode, not just its name. ## Why this matters when auditing a fleet The practical consequence for something like a fleet of fixed-function hospital pharmacy dispensing cabinets, whose suite list is set at commissioning and read years later, is that a TLS 1.3 policy is a **very short document**. There are five entries to have an opinion about, the AES-GCM pair and the ChaCha20-Poly1305 entry cover essentially all interoperable traffic, and there is no longer any way for a weak exchange or a weak authentication choice to hide inside a suite name — those live in the extension lists and must be audited there instead. The flip side is the trap: an auditor who has only ever tightened a 1.2 suite list will look at a five-entry 1.3 list, see nothing dangerous, and conclude the negotiation is fully constrained. It is not. The group policy and the signature policy are now separate surfaces, and they can still be wrong while the suite list is perfect.

  • What does the 8 in TLS_AES_128_CCM_8_SHA256 mean?
    It marks a shortened authentication tag: 8 octets instead of the 16-octet tag the other CCM suite produces. It saves eight octets of overhead on every record, which matters on constrained links, and it reduces forgery resistance in proportion. It is the one place in the TLS 1.3 list where a suite name carries a parameter of the mode rather than just its name.
  • If a TLS 1.3 suite no longer names the key exchange, how do the peers agree on one?
    Through extensions. The client advertises acceptable groups in supported_groups(10) and speculatively sends one or more public shares in key_share(51). If the server wants a group the client offered but did not send a share for, it replies with a HelloRetryRequest asking for that share. The suite selection is entirely independent of that negotiation.
  • Does a short suite list mean a TLS 1.3 deployment is fully constrained?
    No, and assuming so is the common audit mistake. The suite list now constrains only record protection and key derivation. The acceptable groups and the acceptable signature schemes are separate negotiation surfaces with their own policy, and either can be misconfigured while the five-entry suite list looks impeccable.

saying these in an interview costs you the question

  • Saying TLS 1.3 kept the old suites with new names
  • Claiming a TLS 1.3 suite still names the key exchange
  • Stating all five suites are mandatory to implement
  • Treating a short suite list as a fully constrained negotiation
  • Reading the trailing hash as a record MAC hash