draft-moriarty-tls-oldversions-diediedie.xml

<?xml version="1.0" encoding="US-ASCII"?>
<!-- this is version 5 of this xml2rfc template -->
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY rfc2119 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY rfc2223 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2223.xml">
<!ENTITY rfc2578 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2578.xml">
<!ENTITY rfc2579 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2579.xml">
<!ENTITY rfc2580 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2580.xml">
<!ENTITY rfc2629 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2629.xml">
<!ENTITY rfc3410 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3410.xml">
<!ENTITY rfc4181 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4181.xml">
]>
<?rfc toc="yes"?>
<?rfc symrefs="yes"?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?>
<?rfc strict="no"?>
<?rfc rfcedstyle="yes"?>
<?rfc comments="yes"?>
<?rfc inline="yes"?>
<rfc category="std" docName="draft-moriarty-tls-oldversions-diediedie-00"
     ipr="trust200902" updates="[[List TBD]]">
  <front>
    <title abbrev="Deprecating TLSv1.0 and TLSv1.1">Deprecating TLSv1.0 and
    TLSv1.1</title>

    <author fullname="Kathleen Moriarty" initials="K" surname="Moriarty">
      <organization>Dell EMC</organization>

      <address>
        <postal>
          <street>176 South Street</street>

          <city>Hopkinton</city>

          <country>United States</country>
        </postal>

        <email>Kathleen.Moriarty.ietf@gmail.com</email>
      </address>
    </author>

    <author fullname="Stephen Farrell" initials="S." surname="Farrell">
      <organization>Trinity College Dublin</organization>

      <address>
        <postal>
          <street/>

          <city>Dublin</city>

          <region/>

          <code>2</code>

          <country>Ireland</country>
        </postal>

        <phone>+353-1-896-2354</phone>

        <email>stephen.farrell@cs.tcd.ie</email>
      </address>
    </author>

    <date year="2018"/>

    <area>Security Area</area>

    <workgroup>Internet Engineering Task Force</workgroup>

    <keyword>TLS</keyword>

    <keyword>deprecate</keyword>

    <keyword>TLSv1.0</keyword>

    <keyword>TLSv1.1</keyword>

    <abstract>
      <t>This document [if approved] formally deprecates Transport Layer
      Security (TLS) versions 1.0 <xref target="RFC2246"/> and 1.1 <xref
      target="RFC4346"/> and moves these documents to the historic state.
      These versions lack support for current and recommended cipher suites,
      and various government and industry profiiles of applications using TLS
      now mandate avoiding these old TLS versions. TLSv1.2 has been the
      recommended version for IETF protocols since 2008, providing sufficient
      time to transition away from older versions. Products having to support
      older versions increase the attack surface unnecessarily and increase
      opportunities for misconfigurations. Supporting these older versions
      also requires additional effort for library and product maintenance.</t>

      <t>This document updates the backward compatibility sections of TLS RFCs
      [[list TBD]] to prohibit fallback to TLSv1.0 and TLSv1.1. This document
      also updates RFC 7525.</t>
    </abstract>
  </front>

  <middle>
    <section title="Introduction">
      <t>[[Text in double-square brackets, like this, is commentary intended
      to be fixed as the draft evolves. You're already seen that we need to
      figure out the list of RFCs that this'd update in the abstract.]]</t>

      <t>Transport Layer Security (TLS) versions 1.0 <xref target="RFC2246"/>
      and 1.1 <xref target="RFC4346"/> were superceded by TLSv1.2 <xref
      target="RFC5246"/> in 2008, which has now itself been superceded by
      TLSv1.3 <xref target="I-D.ietf-tls-tls13"/>. It is therefore timely to
      further deprecate these old versions. The expection is that TLSv1.2 will
      continue to be used for many years alongside TLSv1.3.</t>

      <t>TLSv1.1 and TLSv1.0 are also actively being deprecated in accordance
      with guidance from government agencies (e.g. <xref
      target="NIST800-52r2">NIST SP 80052r2</xref>) and industry consortia
      such as the Payment Card Industry Association (PCI) <xref
      target="PCI-TLS1"/>.</t>

      <t>The primary technical reasons for deprecating these versions
      include:</t>

      <t><list style="symbols">
          <t>They require implementation of older cipher suites that are no
          longer desirable for cryptographic reasons, e.g. TLSv1.0 makes
          TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA mandatory to implement</t>

          <t>Lack of support for current recommended cipher suites, especially
          using AEAD ciphers which are not supported prior to TLS 1.2</t>

          <!--  Not sure what this is for?
			   Note:
          The registry must remain in support of TLSv1.2, but is updated
          through <xref target="I-D.ietf-tls-iana-registry-updates"/></t>
			-->

          <t>Support for four protocol versions increases the likelihood of
          misconfiguration</t>

          <t>At least one widely-used library has plans to drop TLSv1.1 and
          TLSv1.0 support in upcoming releases; products using such libraries
          would need to use older versions of the libraries to support TLSv1.0
          and TLSv1.1, which is clearly undesirable</t>
        </list></t>

      <t>Deprecation of these versions is intended to assist developers as
      additional justification to no longer support older TLS versions and to
      migrate to a minimum of TLSv1.2. Deprecation also assists product teams
      with phasing out support for the older versions to reduce the attack
      surface and the scope of maintenance for protocols in their
      offerings.</t>

      <!-- duplication - already said in the bullet list above
      <t>Some TLS libraries are considering dropping support for TLSv1.0 and
      TLSv1.1 in upcoming releases. If products do not follow suit because the
      protocol has not been deprecated, multiple libraries may be needed for a
      very small number of deployments. While fixes have been developed to
      address the known vulnerabilities in TLSv1.0 and TLSv1.1, this may not
      continue if library support is eliminated for new releases.</t>
		-->

      <t>[[This draft is being written now so that the TLS WG chairs can just
      hit the "publication requested" button as soon as there is WG consensus
      to deprecate these ancient versions of TLS. The authors however think
      that deprecation now is timely.]]</t>

      <!-- adding the boilerplate below for 2119 and 8174
          -->

      <section title="Terminology">
        <t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
        "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
        "OPTIONAL" in this document are to be interpreted as described in BCP
        14 [RFC2119] [RFC8174] when, and only when, they appear in all
        capitals, as shown here.</t>
      </section>
    </section>

    <section title="Support for Deprecation">
      <t>Industry is actively following guidance provided by NIST and the PCI
      Council deprecating TLSv1.0 and TLSv1.1 by June 30, 2018. TLSv1.2 should
      remain a minimum baseline for TLS support at this time.</t>

      <t>Specific details on attacks against TLSv1.0 and TLSv1.1 as well as
      their mitigations are provided in <xref target="NIST800-52r2">NIST
      SP800-52r2</xref> and referenced RFCs. Although the attacks have been
      mitigated, if support is dropped for future library releases for these
      versions, it is unlikely attacks found going forward will be mitigated
      in older library releases.</t>

      <t>They have provided the following rationale.</t>

      <section title="NIST 800-52r2">
        <t>The following text is copied with permission from <xref
        target="NIST800-52r2">NIST SP800-52r2</xref> section 1.2 History of
        TLS.</t>

        <t>TLS 1.1, specified in <xref target="RFC4346"/>, was developed to
        address weaknesses discovered in TLS 1.0, primarily in the areas of
        initialization vector selection and padding error processing.
        Initialization vectors were made explicit to prevent a certain class
        of attacks on the Cipher Block Chaining (CBC) mode of operation used
        by TLS. The handling of padding errors was altered to treat a padding
        error as a bad message authentication code, rather than a decryption
        failure. In addition, the TLS 1.1 RFC acknowledges attacks on CBC mode
        that rely on the time to compute the message authentication code
        (MAC). The TLS 1.1 specification states that to defend against such
        attacks, an implementation must process records in the same manner
        regardless of whether padding errors exist. Further implementation
        considerations for CBC modes (which were not included in <xref
        target="RFC4346">RFC4346</xref>) are discussed in Section 3.3.2.</t>

        <t>TLS 1.2, specified in <xref target="RFC5246">RFC5246</xref>, made
        several cryptographic enhancements, particularly in the area of hash
        functions, with the ability to use or specify the SHA-2 family
        algorithms for hash, MAC, and Pseudorandom Function (PRF)
        computations. TLS 1.2 also adds authenticated encryption with
        associated data (AEAD) cipher suites.</t>

        <t>TLS 1.3, specified in <xref
        target="I-D.ietf-tls-tls13">TLSv1.3</xref>, represents a significant
        change to TLS that aims to address threats that have arisen over the
        years. Among the changes are a new handshake protocol, a new key
        derivation process that uses the HMAC-based Extract-and-Expand Key
        Derivation Function (HKDF), and the removal of cipher suites that use
        static RSA or DH key exchanges, the CBC mode of operation, or SHA-1.
        The list of extensions that can be used with TLS 1.3 has been reduced
        considerably.</t>
      </section>
    </section>

    <section title="Usage and Support">
      <t>[[This section can be removed upon publication.]]</t>

      <t>Usage statistics for TLSv1.0 and TLSv1.1 vary slightly, but are in
      general very low already and soon to decline further with the impending
      PCI deadline to migrate off of TLSv1.0 by June 30, 2018. As of January
      2018, <xref target="StackExchange">Stackexchange</xref> quoted 4 percent
      of browsers using TLSv1.0.</t>

      <t><xref target="Alexa">The Alexa Top 1 Million Analysis</xref> from
      February 2018 shows that for the sites surveyed, the vast majority
      support TLSv1.2 (98.9 percent), with a mere 0.8 percent using TLSv1.0
      and an even smaller percentage using TLSv1.1.</t>

      <t>Support for TLSv1.0 has been removed or will be by July 2018 from the
      following standards, products, and services:</t>

      <t><list style="symbols">
          <t>3GPP 5G</t>

          <t>[[Numerous web sites...]]</t>

          <t>CloudFare <xref target="CloudFlare"/></t>

          <t>Amazon Elastic Load Balancing <xref target="Amazon"/></t>

          <t>GitHub <xref target="GIT"/></t>
        </list></t>

      <t>Many web sites have taken the action of including the deprecation of
      TLSv1.1 into their plans for deprecating TLSv1.0 for the PCI council
      deadline. Support for TLSv1.1 has been removed or will be by July 2018
      from the following standards, products, and services:</t>

      <t><list style="symbols">
          <t>3GPP 5G Release 16</t>

          <t>GitHub <xref target="GIT"/></t>

          <t>Amazon Elastic Load Balancing <xref target="Amazon"/></t>

          <t>CloudFare <xref target="CloudFlare"/></t>

          <t>[[Numerous web sites...]]</t>
        </list></t>
    </section>

    <section title="Do Not Use TLSv1.0">
      <t>TLSv1.0 MUST NOT be used. <!-- I didn't get the reason for this here: <xref target="RFC8174"/>.  -->
      Negotiation of TLSv1.0 from any version of TLS MUST NOT be
      permitted.</t>

      <t>Any version of TLS is more secure then TLSv1.0 and can be configured
      to prevent interception, though the highest version available is
      preferable.</t>

      <t>Pragmatically, clients MUST NOT send a ClientHello with
      ClientHello.client_version set to {03,01}. Similarly, servers MUST NOT
      send a ServerHello with ServerHello.server_version set to {03,01}. Any
      party receiving a Hello message with the protocol version set to {03,01}
      MUST respond with a "protocol_version" alert message and close the
      connection.</t>

      <t>Historically, TLS specifications were not clear on what the record
      layer version number (TLSPlaintext.version) could contain when sending
      ClientHello. Appendix E of [RFC5246] notes that TLSPlaintext.version
      could be selected to maximize interoperability, though no definitive
      value is identified as ideal. That guidance is still applicable;
      therefore, TLS servers MUST accept any value {03,XX} (including {03,00})
      as the record layer version number for ClientHello, but they MUST NOT
      negotiate TLSv1.0.</t>

      <!-- what's this for? <t>Text derived from <xref target="RFC7568"/></t> -->
    </section>

    <section title="Do Not Use TLSv1.1">
      <t>TLSv1.1 MUST NOT be used. Negotiation of TLSv1.1 from any version of
      TLS MUST NOT be permitted.</t>

      <t>Pragmatically, clients MUST NOT send a ClientHello with
      ClientHello.client_version set to {03,02}. Similarly, servers MUST NOT
      send a ServerHello with ServerHello.server_version set to {03,02}. Any
      party receiving a Hello message with the protocol version set to {03,02}
      MUST respond with a "protocol_version" alert message and close the
      connection.</t>

      <t>Any newer version of TLS is more secure then TLSv1.1 and can be
      configured to prevent interception, though the highest version available
      is preferable. Support for TLSv1.1 is dwindling in libraries and will
      impact security going forward if mitagations for attacks cannot be
      easily addressed and supported in older libraries.</t>

      <t>Historically, TLS specifications were not clear on what the record
      layer version number (TLSPlaintext.version) could contain when sending
      ClientHello. Appendix E of [RFC5246] notes that TLSPlaintext.version
      could be selected to maximize interoperability, though no definitive
      value is identified as ideal. That guidance is still applicable;
      therefore, TLS servers MUST accept any value {03,XX} (including {03,00})
      as the record layer version number for ClientHello, but they MUST NOT
      negotiate TLSv1.1.</t>
    </section>

    <section title="Updates to RFC7525">
      <t>[[Since RFC7525 is BCP195, there'll probably be some process-fun to
      do an update of that. Formally, it may be that this document becomes a
      new part of BCP195 I guess, but we can figure that out with chairs and
      ADs.]]</t>

      <t>This documents updates <xref target="RFC7525"/> Section 3.1.1
      changing SHOULD NOT to MUST NOT as follows:</t>

      <t><list style="symbols">
          <t>Implementations MUST NOT negotiate TLS version 1.0 <xref
          target="RFC2246"/>. <vspace blankLines="1"/> Rationale: TLS 1.0
          (published in 1999) does not support many modern, strong cipher
          suites. In addition, TLS 1.0 lacks a per- record Initialization
          Vector (IV) for CBC-based cipher suites and does not warn against
          common padding errors.</t>

          <t>Implementations MUST NOT negotiate TLS version 1.1 <xref
          target="RFC4346"/>. <vspace blankLines="1"/> Rationale: TLS 1.1
          (published in 2006) is a security improvement over TLS 1.0 but still
          does not support certain stronger cipher suites.</t>
        </list></t>

      <t>This documents updates <xref target="RFC7525"/> Section 3.1.2
      changing SHOULD NOT to MUST NOT as follows:</t>

      <t><list style="symbols">
          <t>Implementations MUST NOT negotiate DTLS version 1.0 <xref
          target="RFC4347"/>. <vspace blankLines="1"/> Version 1.0 of DTLS
          correlates to version 1.1 of TLS (see above).</t>
        </list></t>
    </section>

    <section title="Security Considerations">
      <t>This document deprecates two older protocol versions for security
      reasons already described. The attack surface is reduced when there are
      a smaller number of supported protocols and fallback options are
      removed.</t>
    </section>

    <section title="Acknowledgements">
      <t>Thank you to those that reviewed and improved this document,
      including Yoav Nir, Russ Housley, and David Black.</t>
    </section>

    <section title="IANA Considerations">
      <t>[[This memo includes no request to IANA.]]</t>
    </section>

    <section title="Contributors">
      <t/>
    </section>
  </middle>

  <back>
    <references title="Normative References">
      <?rfc include='reference.RFC.8174'?>

      <?rfc include='reference.RFC.2119'?>

      <?rfc include='reference.RFC.2246'?>

      <?rfc include='reference.RFC.4346'?>

      <?rfc include='reference.RFC.7525'?>
    </references>

    <references title="Informative References">
      <reference anchor="Alexa">
        <front>
          <title>The Alexa Top 1 Million Analysis
          https://scotthelme.co.uk/alexa-top-1-million-analysis-february-2018/</title>

          <author>
            <organization>Will be deleted before publication</organization>
          </author>

          <date year="2018"/>
        </front>
      </reference>

      <reference anchor="StackExchange">
        <front>
          <title>Stackexchange
          https://security.stackexchange.com/questions/177182/is-there-a-list-of-old-browsers-that-only-support-tls-1-0</title>

          <author>
            <organization>StackExchange - will be deleted before
            publication</organization>
          </author>

          <date year="2018"/>
        </front>
      </reference>

      <reference anchor="NIST800-52r2">
        <front>
          <title>NIST SP800-52r2
          https://csrc.nist.gov/CSRC/media/Publications/sp/800-52/rev-2/draft/documents/sp800-52r2-draft.pdf</title>

          <author>
            <organization>National Institute of Standards and
            Technology</organization>
          </author>

          <date year="2018"/>
        </front>
      </reference>

      <reference anchor="PCI-TLS1">
        <front>
          <title>Migrating from SSL and Early TLS
          https://www.pcisecuritystandards.org/documents/Migrating-from-SSL-Early-TLS-Info-Supp-v1_1.pdf</title>

          <author>
            <organization>PCI Security Standards Council</organization>
          </author>

          <date year="2016"/>
        </front>
      </reference>

      <reference anchor="GIT">
        <front>
          <title>GitHub Deprecates TLSv1.0 and TLSv1.1
          https://githubengineering.com/crypto-removal-notice/</title>

          <author>
            <organization>GitHub</organization>
          </author>

          <date year="2018"/>
        </front>
      </reference>

      <reference anchor="CloudFlare">
        <front>
          <title>CloudFlare Deprecated TLSv1.0 and TLSv1.1
          https://blog.cloudflare.com/deprecating-old-tls-versions-on-cloudflare-dashboard-and-api/</title>

          <author>
            <organization>CloudFlare</organization>
          </author>

          <date year="2018"/>
        </front>
      </reference>

      <reference anchor="Amazon">
        <front>
          <title>Amazon Elastic Load Balancing Support Deprecated TLSv1.0 and
          TLSv1.1
          https://aws.amazon.com/about-aws/whats-new/2017/02/elastic-load-balancing-support-for-tls-1-1-and-tls-1-2-pre-defined-security-policies/</title>

          <author>
            <organization>CloudFlare</organization>
          </author>

          <date year="2017"/>
        </front>
      </reference>

      <?rfc include='reference.RFC.5246'?>

      <?rfc include='reference.RFC.7568'?>

      <?rfc include='reference.RFC.4347'?>

      <?rfc include='reference.I-D.ietf-tls-tls13'?>

      <?rfc include='reference.I-D.ietf-tls-iana-registry-updates'?>
    </references>

    <section title="Change Log ">
      <t>Note to RFC Editor: if this document does not obsolete an existing
      RFC, please remove this appendix before publication as an RFC.</t>
    </section>
  </back>
</rfc>