Maximum Version TLS Cipher Suites

In theory SSLv3 and TLS provide for automatic version negotiation. This mechanism works by having the client offer the highest version it supports (in the ClientHello) and then the server selects the highest common version. Unfortunately, experience has shown that broken servers sometimes fail when clients offer higher versions than they support. These failures manifest as TLS handshake failures. ` Some clients (in particular Web Browser clients) respond to these failures by initiating a new connection with a lower version. However, because the attacker can simulate such a failure without having access to the server's keying material, this means that an attacker can force the client back to an earlier version of TLS than the client and server mutually support. The ordinary TLS anti-downgrade mechanisms such as Finished do not provide protection here because the first handshake does not complete at all. The natural defense against this attack is to have a "maximum version" indicator which the client can safely send even to downrev servers but which upgraded servers can check and will thus allow downgrade detection. [Note that SSLv3 defines such a mechanism in the PKCS#1 padding for use to detect SSLv3->SSLv2 rollback.] The natural location for this indicator is in the cipher suite list as servers already ignore unknown cipher suites. (An extension is not suitable as extension-intolerance is one form of incompatibility).

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 RFC 2119.

This document defines six new cipher suites which are used to indicate the maximum version that the client supports. These cipher suites are: Cipher Suite Version Code point TLS_VERSION_SSL3_SCSV SSLv3 TBD TLS_VERSION_TLS_1_0_SCSV TLS 1.0 TBD TLS_VERSION_TLS_1_1_SCSV TLS 1.1 TBD TLS_VERSION_TLS_1_2_SCSV TLS 1.1 TBD TLS_VERSION_DTLS_1_1_SCSV DTLS 1.1 TBD TLS_VERSION_DTLS_1_2_SCSV DTLS 1.2 TBD [[ OPEN ISSUE: Do we really need defns for SSLv3? ... ]]

A client compliant with this specification MUST add to its cipher suite list the SCSV value which corresponds to the highest TLS version it supports for the TLS mode (TLS or DTLS) it is attempting. In cases where a previous attempt to connect to this server has failed and the client is now retrying with a lower version, the client MUST still indicate the highest version, not the lower version it is now attempting. Note that when a user has configured the client to disable a specific version, it is the highest configured version which must be advertised. No more than one SCSV value may be present.

A server compliant with this specification MUST inspect the cipher suites offered by the client to determine if an SCSV value is present. If no SCSV value is present, then the server proceeds with the handshake as usual. If more than one SCSV value is present then the server MUST terminate the connection with a fatal "illegal_parameter" alert. If the SCSV value is present and is equal to ClientHello.client_version, then the server continues the handshake as usual. If the SCSV value is present and is not equal to ClientHello.client_version, then the server MUST terminate the handshake with a fatal "handshake_failure" alert. Note that if a server (a) improperly handles version and/or extension negotiation and (b) implements this specification will experience a hard failure with a newer client which falls back to an older version. This is a feature rather than a bug. It is important that new implementations perform correct version negotiation. The only purpose of this specification is to enable newer clients and servers to detect downgrade attack while not disabling newer clients from commnunications with older, broken, servers.

TLS already provides a mechanism for suppressing downgrade attacks when both implementations are compliant. This mechanism allows servers to detect the situation where they are communicating with a client which has been forced to offer a fresh handshake with a lower version number by an attacker simulating non-compliance. As with the normal TLS anti-downgrade mechanism, the security of this mechanism rests on the security of the Finished handshake calculation. If that fails, then a downgrade attack is still possible. Thus, security is only provided down to the security of the Finished handshake of the weakest mutually supported TLS version. Currently, the Finished handshakes of all TLS versions are believed to be sufficiently secure. However, if future research weakens one of the Finished handshakes to the point where it cannot reliably detect tampering with the handshake messages, then downgrade attack to that version will be possible and defense will require disabling that TLS version.

[TODO]