One document matched: draft-bmoeller-tls-downgrade-scsv-01.xml

<?xml version="1.0" -- -*- mode: XML; indent-tabs-mode: nil; fill-column: 100; -*- -- ?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
    <!ENTITY rfc2119 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml'>
    <!ENTITY rfc2246 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2246.xml'>
    <!ENTITY rfc4346 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4346.xml'>
    <!ENTITY rfc5246 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.5246.xml'>
    <!ENTITY rfc6101 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.6101.xml'>
]>

<rfc category="std"
     ipr="trust200902"
     docName="draft-bmoeller-tls-downgrade-scsv-01"
     updates="2246,4346,5246">

  <?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>76 9th Ave</street>
          <city>New York</city>
          <region>NY</region>
          <code>10011</code>
          <country>USA</country>
        </postal>
        <email>agl@google.com</email>
      </address>
    </author>

    <date year="2013" month="November" day="28"/>

    <abstract>
      <t>
        This document defines a Signaling Cipher Suite Value (SCSV) that prevents
        protocol downgrade attacks on the Transport Layer Security (TLS) protocol.
      </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 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.  Also, handshake errors due to network glitches
        could similary 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 critical if
        they mean losing the TLS extension feature (when 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 to this document, by having the
        client indicate that the current connection attempt is merely a fallback.
      </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"/>.  (It is particularly relevant
        if such 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>
        [[ NOTE IN DRAFT: The following registry allocations require Standards Action,
        i.e. will only be official with the IESG's Standards Track RFC approval. ]]
      </t>

      <t>
        This document allocates a new cipher suite value in the TLS Cipher Suite Registry
        <xref target="RFC5246"/>:
      </t>

      <figure>
        <artwork><![CDATA[
     TLS_FALLBACK_SCSV          {0x56, 0x00}
        ]]>
        </artwork>
      </figure>

      <t>
        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.
      </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 inappropriate_fallback alert.
          </t>
        </list>

        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>
    </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 in order to avoid interoperability problems
        with legacy servers.  This section specifies when to send it.

        <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.  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.
          </t>
        </list>
      </t>

      <t>
        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_FALLBACK_SCSV.)
      </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.  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_FALLBACK_SCSV could be omitted for
        this particular protocol downgrade step.
      </t>

      <t>
        However, it is particularly 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>
  </middle>


  <back>
    <references title="Normative References">
      &rfc2119;
      &rfc2246;
      &rfc4346;
      &rfc5246;
    </references>

    <references title="Informal References">
      &rfc6101;
    </references>


    <section anchor="app.ack" title="Acknowledgements">

      <t>
        This specification was inspired by an earlier proposal by Eric Rescorla.
      </t>
    </section>
  </back>

</rfc>