One document matched: draft-ietf-tls-downgrade-scsv-05.xml
<?xml version="1.0"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY rfc2119 PUBLIC '' 'http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml'>
<!ENTITY rfc2246 PUBLIC '' 'http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2246.xml'>
<!ENTITY rfc4346 PUBLIC '' 'http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4346.xml'>
<!ENTITY rfc4347 PUBLIC '' 'http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4347.xml'>
<!ENTITY rfc5246 PUBLIC '' 'http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5246.xml'>
<!ENTITY rfc6101 PUBLIC '' 'http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6101.xml'>
<!ENTITY rfc6347 PUBLIC '' 'http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6347.xml'>
]>
<rfc category="std"
ipr="trust200902"
docName="draft-ietf-tls-downgrade-scsv-05"
updates="2246, 4346, 4347, 5246, 6347">
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<?rfc toc="yes" ?>
<?rfc symrefs="yes" ?>
<?rfc sortrefs="yes"?>
<?rfc iprnotified="no" ?>
<?rfc strict="yes" ?>
<front>
<title abbrev="TLS Fallback SCSV">
TLS Fallback Signaling Cipher Suite Value (SCSV) for Preventing Protocol Downgrade Attacks
</title>
<author initials="B." surname="Moeller" fullname="Bodo Moeller">
<organization abbrev="Google">Google Switzerland GmbH</organization>
<address>
<postal>
<street>Brandschenkestrasse 110</street>
<code>8002</code> <city>Zurich</city>
<country>Switzerland</country>
</postal>
<email>bmoeller@acm.org</email>
</address>
</author>
<author fullname="Adam Langley" initials="A." surname="Langley">
<organization abbrev="Google">
Google Inc.
</organization>
<address>
<postal>
<street>345 Spear St</street>
<city>San Francisco</city>
<region>CA</region>
<code>94105</code>
<country>USA</country>
</postal>
<email>agl@google.com</email>
</address>
</author>
<date year="2015" month="February" day="20"/>
<abstract>
<t>
This document defines a Signaling Cipher Suite Value (SCSV) that prevents
protocol downgrade attacks on the Transport Layer Security (TLS)
and Datagram Transport Layer Security (DTLS) protocols.
It updates RFC 2246, RFC 4346, RFC 4347, RFC 5246, and RFC 6347.
Server update considerations are included.
</t>
</abstract>
</front>
<middle>
<section anchor="sec.intro" title="Introduction">
<t>
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.
</t>
<t>
While such fallback retries 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. Also, handshake errors due to network glitches
could similarly be misinterpreted as interaction with a legacy server and result in a
protocol downgrade.
</t>
<t>
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.2);
they can be particularly harmful when the result is loss of the TLS extension feature
by downgrading to SSL 3.0. This document
defines a Signaling Cipher Suite Value (SCSV) that can be employed to prevent unintended
protocol downgrades between clients and servers that comply with this document, by having
the client indicate that the current connection attempt is merely a fallback,
and by having the server return a fatal alert if it detects an inappropriate fallback.
(The alert does not necessarily indicate an intentional downgrade attack, since
network glitches too could result in inappropriate fallback retries.)
</t>
<t>
The fallback SCSV defined in this document is not a suitable 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.
</t>
<t>
This specification applies to implementations of TLS 1.0 <xref target="RFC2246"/>, TLS 1.1
<xref target="RFC4346"/>, and TLS 1.2 <xref target="RFC5246"/>,
and to implementations of DTLS 1.0 <xref target="RFC4347"/> and
DTLS 1.2 <xref target="RFC6347"/>.
(It is particularly relevant if the TLS implementations also include support for predecessor
protocol SSL 3.0 <xref target="RFC6101"/>.)
It can be applied similarly to later protocol versions.
</t>
<t>
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
<xref target="RFC2119"/>.
</t>
</section>
<section anchor="sec.values" title="Protocol values">
<t>
This document defines a new TLS cipher suite value:
</t>
<figure>
<artwork><![CDATA[
TLS_FALLBACK_SCSV {0x56, 0x00}]]>
</artwork>
</figure>
<t>
This is a signaling cipher suite value (SCSV), 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.
</t>
<t>
This document also allocates a new alert value in the TLS Alert Registry
<xref target="RFC5246"/>:
</t>
<figure>
<artwork><![CDATA[
enum {
/* ... */
inappropriate_fallback(86),
/* ... */
(255)
} AlertDescription;]]>
</artwork>
</figure>
<t>
This alert is only generated by servers, as described in <xref target="sec.server"/>.
It is always fatal.
</t>
</section>
<section anchor="sec.server" title="Server behavior">
<t>
This section specifies server behavior when receiving the TLS_FALLBACK_SCSV cipher suite
from a client in ClientHello.cipher_suites.
<list style="symbols">
<t>
If TLS_FALLBACK_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 inappropriate_fallback
alert (unless it responds with a fatal protocol_version alert because
the version indicated in ClientHello.client_version is unsupported).
The record layer version number for this alert MUST be set to
either ClientHello.client_version
(as it would for the Server Hello message if the server was continuing the handshake),
or to the record layer version number used by the client.
</t>
<t>
Otherwise (either TLS_FALLBACK_SCSV does not appear, or it appears and the client's
protocol version is at least the highest protocol version supported by the server),
the server proceeds with the handshake as usual.
</t>
</list>
</t>
<t>
(A protocol version is supported by the server if, in response to appropriate Client Hello
messages, the server would use it for ServerHello.server_version. If a particular protocol
version is implemented but completely disabled by server settings, it is not considered
supported. For example, if the implementation's highest protocol version is TLS 1.2 but the
server operator has disabled this version, a TLS 1.1 Client Hello with TLS_FALLBACK_SCSV
does not warrant responding with an inappropriate_fallback alert.)
</t>
</section>
<section anchor="sec.client" title="Client behavior">
<t>
The TLS_FALLBACK_SCSV cipher suite value is meant for use by clients that repeat a
connection attempt with a downgraded protocol (perform a "fallback retry") in order to work
around interoperability problems with legacy servers.
<list style="symbols">
<t>
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_FALLBACK_SCSV cipher suite value in ClientHello.cipher_suites;
see <xref target="sec.security"/> for security considerations for this recommendation.
(The client SHOULD put TLS_FALLBACK_SCSV after all cipher suites
that it actually intends to negotiate.)
</t>
<t>
As an exception to the above, 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.
(In this case, it is assumed that the client already knows the highest protocol version
supported by the server: see <xref target="RFC5246"/>, Appendix E.1.)
</t>
<t>
If a client sets ClientHello.client_version to its highest supported protocol version,
it MUST NOT include TLS_FALLBACK_SCSV in ClientHello.cipher_suites.
</t>
</list>
</t>
<t>
(A protocol version is supported by the client if the client normally attempts to use it in
handshakes. If a particular protocol version is implemented but completely disabled by
client settings, it is not considered supported. For example, if the implementation's
highest protocol version is TLS 1.2 but the user has disabled this version, a TLS 1.1
handshake is expected and does not warrant sending TLS_FALLBACK_SCSV.)
</t>
<t>
Fallback retries could be caused by events such as network glitches, and a client including
TLS_FALLBACK_SCSV in ClientHello.cipher_suites may receive an inappropriate_fallback alert
in response, indicating that the server supports a higher protocol version. Thus, if a
client intends to use retries to work around network glitches, it should then retry with the
highest version it supports.
</t>
<t>
If a client keeps track of the highest protocol version apparently supported by a particular
server for use in ClientHello.client_version later, then if the client receives an
inappropriate_fallback alert from that server, it MUST clear the memorized highest supported
protocol version.
(Without the alert, it is a good idea -- but outside of the scope of this document -- for
clients to clear that state after a time-out, since the server's highest protocol version
could change over time.)
</t>
<t>
For clients that use client-side TLS False Start <xref target="false-start"/>, it is
important to note that the TLS_FALLBACK_SCSV mechanism cannot protect the first round of
application data sent by the client: refer to the Security Considerations in
<xref target="false-start"/>, Section 6.
</t>
</section>
<section anchor="sec.ops" title="Operational Considerations">
<t>
Updating legacy server clusters to simultaneously add support for newer protocol versions
and support for TLS_FALLBACK_SCSV can have complications, if the legacy server
implementation is not "version-tolerant" (cannot properly handle Client Hello messages
for newer protocol versions):
fallback retries required for interoperability with old server nodes might be rejected by
updated server nodes.
</t>
<t>
Updating the server cluster in two consecutive steps makes this safe:
first, update the server software but leave the highest supported version unchanged
(by disabling newer versions in server settings);
then, after all legacy (version-intolerant) implementations have been removed,
change server settings to allow new protocol versions.
</t>
</section>
<section anchor="sec.security" title="Security Considerations">
<t>
<xref target="sec.client"/> does not require client implementations to send
TLS_FALLBACK_SCSV in any particular case, it merely recommends it; behavior can be adapted
according to the client's security needs.
It is important to remember that omitting TLS_FALLBACK_SCSV enables downgrade attacks,
so implementors must take into account whether the protocol version given by
ClientHello.client_version still provides an acceptable level of protection.
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 preferable to
potentially not being able to connect at all: so TLS_FALLBACK_SCSV could be omitted for
this particular protocol downgrade step.
</t>
<t>
However, it is strongly recommended to send TLS_FALLBACK_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.
</t>
</section>
<section anchor="sec.iana" title="IANA Considerations">
<t>
[[ TO BE REMOVED: The requested registry allocations require Standards Action,
i.e., will only be official with the IESG's Standards Track RFC approval.
Since this document is currently an Internet-Draft, IANA so far has in fact
not added the cipher suite number and alert number to the
respective registries. The values as shown are used in early
implementations. ]]
</t>
<texttable>
<ttcol align='center'>Value</ttcol>
<ttcol align='center'>Description</ttcol>
<ttcol align='center'>DTLS-OK</ttcol>
<ttcol align='center'>Reference</ttcol>
<c>0x56,0x00</c>
<c>TLS_FALLBACK_SCSV</c>
<c>Y</c>
<c>(this document)</c>
<postamble>
http://www.iana.org/assignments/tls-parameters
</postamble>
</texttable>
<texttable>
<ttcol align='center'>Value</ttcol>
<ttcol align='center'>Description</ttcol>
<ttcol align='center'>DTLS-OK</ttcol>
<ttcol align='center'>Reference</ttcol>
<c>86</c>
<c>inappropriate_fallback</c>
<c>Y</c>
<c>(this document)</c>
<postamble>
http://www.iana.org/assignments/tls-parameters
</postamble>
</texttable>
<t>
IANA has added TLS cipher suite number 0x56,0x00 with name
TLS_FALLBACK_SCSV to the TLS Cipher Suite registry,
and alert number 86 with name inappropriate_fallback to the
TLS Alert registry.
</t>
</section>
</middle>
<back>
<references title="Normative References">
&rfc2119;
&rfc2246;
&rfc4346;
&rfc4347;
&rfc5246;
&rfc6347;
</references>
<references title="Informative References">
&rfc6101;
<reference anchor="false-start">
<front>
<title>Transport Layer Security (TLS) False Start</title>
<author initials="A." surname="Langley" fullname="Adam Langley">
<organization />
</author>
<author initials="N." surname="Modadugu" fullname="Nagendra Modadugu">
<organization />
</author>
<author initials="B." surname="Moeller" fullname="Bodo Moeller">
<organization />
</author>
<date month="November" year="2014" />
</front>
<seriesInfo name="Work in Progress," value="draft-bmoeller-tls-falsestart-01" />
</reference>
</references>
<section anchor="app.ack" title="Acknowledgements">
<t>
This specification was inspired by an earlier proposal by Eric Rescorla. We also thank
Daniel Kahn Gillmor, Joe Saloway, Brian Smith, Martin Thomson, and others in the TLS Working
Group for their feedback and suggestions.
</t>
</section>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-23 08:52:38 |