TLS Cipher Suites: The Full IANA Registry

What is a TLS cipher suite?

A cipher suite is a named bundle of cryptographic choices that a TLS client and server agree on during the handshake: how they establish a shared key, how they authenticate each other, and how they encrypt and authenticate the data that follows. Each bundle has a two-byte identifier, and IANA keeps the registry of them.

That registry holds 448 entries. 356 are named suites; the rest are unassigned ranges and reserved values. The names read like a specification because they are one — TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 says ephemeral elliptic-curve Diffie-Hellman for the key exchange, RSA for authentication, AES-128 in GCM mode for the data, SHA-256 for the handshake. TLS 1.3 shortened them: it removed the key exchange and authentication from the name, so TLS_AES_128_GCM_SHA256 names only the record protection.

The registry also carries a column called Recommended, and that column is why this page exists. Nearly every table you can find reproduces it as a tick or a cross. It has four values, and the difference between two of them is the thing people get wrong.

How to use it

1. Paste an identifier. Any spelling works — 0x13,0x01 as the registry writes it, 1301 from a packet capture, 13 01 or 13:01 from a config file. You get the suite name, its marking, whether DTLS may use it, and links to the RFCs that define it.
2. Or search by name. Type CHACHA20, or GCM, or an RFC number. The table underneath shows named suites by default; one checkbox brings back the reserved and unassigned entries too.
3. Read the marking as a statement, not a score. Each result spells out what its letter means in the words the defining RFC uses, because the short version is what misleads people.

The Recommended column has four values

RFC 8447 created the column and RFC 9847 amended it in December 2025 to carry four values. Y means recommended, and changing it in either direction takes IETF Standards Action. D means discouraged — RFC 9847 describes it as marking a weak cryptographic algorithm, or one that might cause interoperability problems in deployment. A blank is used for values that are unassigned or reserved.

N is the one that misleads. In the RFC's own words, it means the item has not been evaluated by the IETF and the IETF has made no statement about its suitability — and it says explicitly that this does not necessarily mean the mechanism is flawed, only that no consensus exists. N is the absence of an opinion. It is the default for anything nobody has put through the process.

That distinction is exactly why D was added. Before it existed, N was carrying both meanings at once: nothing to say, and this is a bad idea. Splitting them was the point of the 2025 amendment, and in July 2026 RFC 10015 moved a large block of key exchange methods from N into D. Any table published before those dates disagrees with this one, and the disagreement is not a typo.

Counted today: of the 356 named suites, 14 are recommended, 248 are discouraged, and 94 carry no IETF statement. Under four per cent are marked Y, and that set is essentially the TLS 1.3 suites plus the ECDHE suites using AEAD ciphers.

The letters do not rank strength

Here is the pair that settles it. TLS_RSA_WITH_3DES_EDE_CBC_SHA — no forward secrecy, a 64-bit block cipher, an algorithm long past retirement — is marked D. TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA — ephemeral key exchange, AES — is marked N.

Read as a ranking, the column says the 3DES suite is the better-regarded of the two, which is absurd. Read correctly, it says something quite different: the IETF has actively discouraged the first, and has simply never issued a statement about the second. Those are claims about the standards process, not measurements of cryptographic strength, and no amount of squinting turns one into the other.

This is why the tool spells the meaning out on every result instead of showing a badge. A badge is a ranking whether you intend it or not.

The entries that are not suites

Sixty-nine entries are unassigned ranges and seven are reserved, but sixteen are worth knowing about individually. They are GREASE values, registered by RFC 8701, and they exist to be meaningless. Their identifiers all have the shape 0x0A,0x0A, 0x1A,0x1A and so on up, and clients send them deliberately, expecting servers to ignore them.

The purpose is to keep the protocol from calcifying. If implementations only ever see the values that exist today, some of them will quietly start rejecting anything else, and the next real extension becomes unshippable. Sending values that mean nothing keeps every implementation honest about ignoring what it does not recognise. Looking one up here returns it as GREASE rather than as an unknown, because someone who finds 0x1A,0x1A in a capture deserves an answer.

What this page will not do

It will not tell you which suites to enable. That depends on what your clients support, what compliance regime you answer to, and what your TLS library actually implements — and the registry answers none of those questions. It records what the IETF has said about each entry, and this page reports that faithfully rather than converting it into a configuration you should paste somewhere.

It is also a snapshot. The registry gains entries and the markings change; two of the three RFCs that define this column are less than a year old, which should tell you how live the column is. Anything you read here about a specific suite is worth confirming against IANA before it goes into a policy.

Finally, a suite being registered says nothing about whether your software supports it, and a suite being recommended says nothing about whether the rest of your configuration is sound. Most real TLS problems are certificates, protocol versions and key sizes rather than the cipher suite list.

Why is it free?

The whole registry is a few kilobytes shipped with the page and searched in your browser. Nothing you type is uploaded, nothing is logged, and there is no account to make.

No sign-up, no limits, and no watermark on anything you copy out.