]> Google Switzerland GmbH

Brandschenkestrasse 110 8002 Zurich Switzerland bmoeller@acm.org

This document defines a Signaling Cipher Suite Value (SCSV) that can be used to prevent protocol downgrades for Transport Layer Security (TLS).

To work around interoperability problems with legacy servers, many TLS client implementations do not rely on the TLS protocol version negotiation mechanism alone, but will intentionally reconnect using a downgraded protocol if initial handshake attempts fail. Such clients may fall back to connections in which they announce a version as low as TLS 1.0 (or even its predecessor, SSL 3.0) as the highest supported version, and make no attempt of using TLS extensions. While such protocol downgrades can be a useful last resort for connections to actual legacy servers, there's a risk that active attackers could exploit the downgrade strategy to weaken the cryptographic security of connections. (For example, if a server requires the client's Supported Elliptic Curves Extension to choose a forward-secure key exchange algorithm, the attacker could interfere with connections using this extension to get the client and server to instead use a key exchange algorithm that does not providing forward secrecy.) Also, handshake errors due to network glitches could similary be misinterpreted as interaction with a legacy server and result in a protocol downgrade. All unnecessary protocol downgrades are undesirable (e.g., from TLS 1.2 to TLS 1.1 if both the client and the server actually do support TLS 1.1); they can be particularly critical if they mean losing the TLS extension feature (when downgrading to TLS 1.0 without extensions, or to SSL 3.0). This document defines a Signaling Cipher Suite Value (SCSV) that can be employed to prevent such protocol downgrades between clients and servers that comply to this document. This specification applies to implementations of TLS 1.0 , TLS 1.1 , and TLS 1.2 . (It is particularly relevant if such implementations also include support for predecessor protocol SSL 3.0 .) It can be applied similarly to later protocol versions. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in .

This document defines one new cipher suite value: [[Code point TBD.]] This is a signaling cipher suite value, i.e., it does not actually correspond to a suite of cryptosystems, and it can never be selected by the server in the handshake; rather, its presence in the client hello message serves as a backwards-compatible signal from the client to the server.

This section specifies server behavior when receiving the TLS_DOWNGRADE_SCSV cipher suite from a client in ClientHello.cipher_suites. If TLS_DOWNGRADE_SCSV appears in ClientHello.cipher_suites and the highest protocol version supported by the server is higher than the version indicated in ClientHello.client_version, the server MUST respond with a (fatal) protocol_version alert. If TLS_DOWNGRADE_SCSV appears in ClientHello.cipher_suites and the ClientHello message does not include field client_hello_extension_list at all (, , ), the server MUST respond with a (fatal) protocol_version alert. Otherwise (either TLS_DOWNGRADE_SCSV does not appear, or it appears *and* the client's protocol version is at least the highest protocol version supported by the server *and* there is a client_hello_extension_list - possibly empty), the server proceeds with the handshake as usual. (Note that the TLS specifications require server implementations that do not support TLS extensions to tolerate extra data at the end of the ClientHello message, at the location where the later specifications added the field client_hello_extension_list. The server behavior mandated here relies on that requirement; intolerance for such extra data is a bug that must be fixed before adding server-side support for TLS_DOWNGRADE_SCSV.)

The TLS_DOWNGRADE_SCSV cipher suite value is meant for use by clients that repeat a connection attempt with a downgraded protocol in order to avoid interoperability problems with legacy servers. This section specifies when to send it. If a client sends a ClientHello.client_version containing a lower value than the latest (highest-valued) version supported by the client, it SHOULD include the TLS_DOWNGRADE_SCSV cipher suite value in ClientHello.cipher_suites. This does not apply when the client intends to perform an abbreviated handshake to resume a previously negotiated session and sets ClientHello.client_version to the protocol version negotiated for that session. If a client that supports TLS extensions and has TLS extensions to send in the handshake entirely omits client_hello_extension_list from the ClientHello message, it SHOULD include the TLS_DOWNGRADE_SCSV cipher suite value in ClientHello.cipher_suites. Note that in the above, a protocol version is not considered supported by the client if it has been disabled by any applicable system or user settings: it is about the highest protocol version that the client would attempt using in a handshake, not about the highest protocol version implemented if its use is not actually enabled. (For example, if the implementation supports TLS 1.2 but the user has disabled this protocol version, a TLS 1.1 handshake is expected and does not warrant sending TLS_DOWNGRADE_SCSV.)

does not require client implementations to send TLS_DOWNGRADE_SCSV in any particular case, it merely recommends it; behavior can be adapted according to the client's security needs. For example, during the initial deployment of a new protocol version (when some interoperability problems may have to be expected), smoothly falling back to the previous protocol version in case of problems may be preferrable to potentially not being able to connect at all: so TLS_DOWNGRADE_SCSV could be omitted for this particular protocol downgrade step. However, it is particularly strongly recommended to sent TLS_DOWNGRADE_SCSV when downgrading to SSL 3.0 as the CBC cipher suites in SSL 3.0 have weaknesses that cannot be addressed by implementation workarounds like the remaining weaknesses in later (TLS) protocol versions.

&rfc2119; &rfc2246; &rfc4346; &rfc5246; &rfc3546; &rfc4366; &rfc4492; &rfc6101;

This specification was inspired by an earlier proposal by Eric Rescorla.