An audit narrows a server's TLS 1.2 suite list, yet live TLS 1.3 connections still negotiate an unlisted suite — why?

## One list on the wire, two policies behind it This failure is common precisely because the wire picture and the configuration picture do not match. On the **wire** there is one list. A `ClientHello` carries a single `cipher_suites` field holding code points from both families — the TLS 1.3 entries and whatever TLS 1.2 entries the client also supports. There is no separate per-version list in the message. In a **deployment** there are two policies, because the server must decide independently which 1.2 suites and which 1.3 suites it will accept. The order of operations is what ties them together: 1. The server reads `supported_versions(43)` and selects the protocol version. 2. Only then does it select a cipher suite — from the family valid for that version. 3. Its acceptable set for the *other* version plays no part in that selection. An audit that tightens the 1.2 list has therefore changed step 3 for one branch of step 1 and nothing at all for the other. Every connection that negotiated 1.3 goes on choosing from the 1.3 policy, untouched. ## Why a 1.3 suite can never be the same suite as a 1.2 one Two independent reasons, and it is worth giving both: - **Different code points, defined for different versions.** The 1.3 entries were registered as new values — `{0x13,0x01}` through `{0x13,0x05}` — and their meaning is defined for TLS 1.3. A 1.2 suite's code point is not usable to mean a 1.3 suite, and the reverse is equally untrue. - **Different contents.** A 1.2 token names four things: exchange, authentication, bulk cipher, and MAC or PRF hash. A 1.3 token names two: the AEAD algorithm and the derivation hash. Even where the record protection matches exactly, the 1.2 entry is additionally constraining an exchange and a signature type that the 1.3 entry says nothing about, because those moved into `supported_groups(10)` and `signature_algorithms(13)`. So "we allow AES-128-GCM" is not a single policy statement. It is two, and they are enforced on different connections. ## What the audit should have checked For a fleet of fixed-function hospital pharmacy dispensing cabinets whose profile was written at commissioning and is being reviewed years later by someone who did not write it, the checklist is: 1. **The version floor**, because it decides which suite policy is even reachable. 2. **The 1.2 acceptable set**, if 1.2 is still permitted at all. 3. **The 1.3 acceptable set**, separately, as its own list. 4. **The group policy and the signature policy**, because on 1.3 those carry decisions that used to sit inside a suite token — an audit confined to suite lists cannot see them. 5. **The ordering policy**, understood as a tiebreak among accepted suites rather than as a control on which are accepted. ## The reverse mistake, which is just as common The mirror-image error is tightening only the 1.3 list and assuming the deployment is hardened, while 1.2 remains enabled with a permissive set behind it. Any client that cannot do 1.3 — and on a fleet commissioned over many years there will be some — lands on 1.2 and is governed entirely by the list nobody edited. The habit that prevents both: **read a suite policy as a function of the negotiated version, never as a single global list**, and confirm which version the connection you are looking at actually negotiated before you reason about which suite it chose. A capture, or a log line that records both the negotiated version and the selected suite together, settles it in one line; a configuration file read on its own never will.