What does TLS_FALLBACK_SCSV in a client's retry after a failed handshake oblige the server to do?

## The problem it addresses Version negotiation inside one handshake is protected: the final handshake messages bind the transcript, so a peer that edited the version fields is detected before application data flows. The gap `RFC 7507` closes is outside that. Some clients, faced with a handshake that failed for any reason at all, retry with a lower version offered. An attacker who can drop or reset connections can therefore drive a client down the version ladder without touching a single handshake message — each individual handshake is honest, and the downgrade happens between them. That retry behaviour existed because peers on the network genuinely did reject hellos they did not understand. The dance was a compatibility workaround, and it turned into a downgrade lever. ## The signal `TLS_FALLBACK_SCSV {0x56, 0x00}` is a **signalling cipher suite value**: an entry the client adds to the ClientHello's cipher suite list which names no cipher and is never selected. Carrying it there rather than in an extension is the whole design point. The fallback is happening because something on the path or at the server choked on the previous hello, and extensions are exactly what such a peer is likely to choke on. A cipher suite list entry is parsed by anything that parses a hello at all. Its meaning is narrow and precise: *this hello is a retry, and it offers less than the highest version I support*. A client sends it only on a retry, never on a first attempt at its best version. ## The server's rule, and the condition on it The rule has two branches, and getting the condition right is the whole question: 1. The server sees the signalling value **and** supports a protocol version higher than the one this hello offers. A genuine peer offering less than the server's best, having just failed, is the signature of an induced downgrade — so the server sends a fatal `inappropriate_fallback(86)` alert and abandons the handshake. 2. The server sees the signalling value and the hello already offers the highest version the server supports. Nothing is wrong: the client stepped down from a version this server never had. The handshake continues normally. The second branch is why the alert exists as a condition rather than as a reflex. A server that fired on the mere presence of the value would break every client that legitimately fell back to the server's own best version. ## What it buys, and what it does not | threat | covered by | |---|---| | version fields edited inside one handshake | the handshake transcript check in the final messages | | a client driven down the ladder by repeated killed handshakes | `TLS_FALLBACK_SCSV` and `inappropriate_fallback(86)` | | a server that genuinely supports nothing higher | not a downgrade at all; a configuration limit | | a client that never retries at a lower version | needs no signal; it has no ladder to be pushed down | The last row is worth stating in an interview, because it is the honest conclusion: the strongest form of this defence is a client that does not perform an insecure retry in the first place. The signalling value is what makes the retry survivable for clients that do. ## Related prohibitions The fallback question is also settled at the version level for the retired protocols. `RFC 7568` prohibits SSL 3.0 and prohibits falling back to it from any version of TLS, which means a downgrade that ends at SSL 3.0 is refused by the version rule independently of any signalling value. ## Operating it on a long-lived bus On a settlement bus with counterparties that upgrade on their own timetable, the operational questions are: - **Does your client library retry at a lower version on failure at all?** If it does, the signalling value must be present on those retries, or the retry is an unmonitored downgrade path. - **Does your server enforce the condition?** An `inappropriate_fallback(86)` alert observed in logs is information, not noise: something caused a peer's first handshake to fail. That is either an attacker or a broken path element, and both are worth finding. - **What does a counterparty see when you enforce it?** A peer whose first attempt fails for an unrelated reason — a path problem, a stale configuration — will now get a hard failure on the retry rather than a quiet, weaker connection. That is the intended behaviour, and it must be explainable to the counterparty before it happens at month end. The summary an auditor wants is that the signal turns a silent weakening into a visible refusal, and that the refusal is conditional on the server genuinely having had something better to offer.