TLS Fallback Signaling Cipher Suite Value (SCSV) for Preventing Protocol Downgrade Attacks
Extracted elements (18)
The fallback SCSV is explicitly not a substitute for proper TLS version negotiation. TLS implementations need to properly handle TLS version negotiation and extensibility mechanisms to avoid the security issues and connection delays associated with fallback retries.
The inappropriate_fallback alert does not necessarily indicate an intentional downgrade attack, since network glitches can also cause inappropriate fallback retries. The alert signals any inappropriate fallback, not just adversarial ones.
The SCSV mechanism uses a cipher suite code point rather than a TLS extension so that it is backwards-compatible with all TLS versions, including those that do not support extensions. This allows signaling even during a fallback to very old protocol versions.
A protocol version is considered supported by the server only if the server would actually use it in ServerHello; if a version is implemented but completely disabled by server settings, it is not considered supported and does not trigger the inappropriate_fallback alert.
Updating legacy server clusters to simultaneously add newer protocol versions and TLS_FALLBACK_SCSV support is risky if old nodes are version-intolerant. The recommended approach is a two-step upgrade: first deploy SCSV support without enabling new versions, then enable new versions only after all version-intolerant nodes are removed.
If a client receives an inappropriate_fallback alert from a server for which it has memorized the highest protocol version, it MUST clear that memorized value, as the server may have been upgraded.
If a client sends a ClientHello.client_version lower than its highest supported version (i.e., a fallback retry), it SHOULD include TLS_FALLBACK_SCSV in ClientHello.cipher_suites, placed after all cipher suites it actually intends to negotiate.
If a client sets ClientHello.client_version to its highest supported protocol version, it MUST NOT include TLS_FALLBACK_SCSV in ClientHello.cipher_suites.
If TLS_FALLBACK_SCSV appears in ClientHello.cipher_suites and the server's highest supported protocol version is higher than ClientHello.client_version, the server MUST respond with a fatal inappropriate_fallback alert (unless it responds with a fatal protocol_version alert because the client's version is unsupported).
The record layer version number for the inappropriate_fallback alert MUST be set to either ClientHello.client_version or to the record layer version number used by the client.
When a client intends to resume a session and sets ClientHello.client_version to the protocol version negotiated for that session, it MUST NOT include TLS_FALLBACK_SCSV in ClientHello.cipher_suites.
A new TLS alert value inappropriate_fallback (86) is defined. It is always fatal and is only generated by servers when they detect an inappropriate protocol downgrade.
TLS_FALLBACK_SCSV is a new cipher suite value with code point {0x56, 0x00}. It is a Signaling Cipher Suite Value (SCSV) and cannot be selected by the server; its presence in ClientHello.cipher_suites signals to the server that the client is performing a fallback retry.
IANA added inappropriate_fallback with alert number 86 (DTLS-OK: Y) to the TLS Alert Registry, referencing RFC 7507.
IANA added TLS_FALLBACK_SCSV with cipher suite number 0x56,0x00 (DTLS-OK: Y) to the TLS Cipher Suite Registry, referencing RFC 7507.
It is strongly recommended to send TLS_FALLBACK_SCSV when downgrading to SSL 3.0, because the CBC cipher suites in SSL 3.0 have weaknesses that cannot be addressed by implementation workarounds, unlike later TLS versions.
Omitting TLS_FALLBACK_SCSV enables downgrade attacks. Implementors must consider whether the protocol version in ClientHello.client_version still provides an acceptable level of protection before choosing to omit the SCSV.
TLS_FALLBACK_SCSV cannot protect application data sent by clients using TLS False Start, since that data is sent before the server's alert can be received. Implementors using False Start must consult its own security considerations.