A TLS connection has two ends. Every extension mechanism in Chapter 4 except the first introduces something the peer must recognise, and this chapter treats the consequences systematically. Constraint C4 is the subject.
| Path | Peer must change | Deployable against |
|---|---|---|
| 1. Implementation substitution | No | Anything, including the public web |
| 2. New group | Yes | Both endpoints under one administration |
| 3. New signature algorithm | Yes, plus certificate support | As above, with a PKI that issues such certificates |
| 4. New cipher suite | Yes | Both endpoints under one administration |
The table is the chapter's main content, and the design consequence is that paths 2–4 belong to closed deployments. Internal service meshes, an organisation's own client software, embedded fleets with managed firmware, and test environments are all appropriate; a public-facing web server is not, because the peer is a browser whose algorithm support the deployment does not control and will not change.
The natural response to the above is to configure the custom algorithms alongside the standard ones, so that peers supporting them use them and others fall back. This works, and for a migration it is the right configuration.
It is a trap when the deployment's purpose is compliance, for exactly the reason given in §14.2: a fallback that succeeds silently produces connections that do not meet the requirement the deployment exists to meet, and produces them indistinguishably from ones that do. A deployment must decide which of these it is — migration or requirement — and configure accordingly. It cannot have both properties at once, and configurations that appear to offer both are in fact migration configurations with a compliance intention attached.
The design confines itself to TLS 1.3 (§6.5), and the capability entries carry minimum and maximum version parameters to enforce it (§10.6). The reason is structural: TLS 1.2 suites encode key exchange and authentication in the suite identifier, and its key derivation differs from the 1.3 schedule. An algorithm offered in both without regard to the difference will be negotiated in a version whose machinery it does not fit.
A deployment that must support TLS 1.2 peers should do so with standard algorithms and confine the custom path to 1.3, rather than attempt to span both.
Two practical effects deserve mention. Network equipment that inspects handshakes may reject or mishandle unrecognised code points; this is the ordinary experience of deploying anything new in TLS, and it is discovered in testing against the actual network path rather than in a laboratory.
Conversely, monitoring infrastructure that identifies connections by cipher suite will report the custom suite as unknown. Security monitoring that alerts on unrecognised suites will alert on every connection the deployment intended to create — a false positive generated by the deployment itself, which should be anticipated rather than discovered during an incident.
Interoperability claims should be established against an implementation that is not the one under development. Two endpoints built from the same source with the same provider will agree with each other even when both are wrong — the shared-bug failure mode, which is precisely what interoperability testing exists to detect.
Where a second independent implementation is unavailable, the weaker but still useful substitute is to verify against independently computed test vectors at each layer: the algorithm outputs, the key schedule (§15.6), and the wire encodings (§10.2). This does not establish interoperability, and a paper reporting such testing should not claim that it does.