<?xml version="1.0" encoding="US-ASCII"?>
<!-- This template is for creating an Internet Draft using xml2rfc,
     which is available here: http://xml.resource.org. -->
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!-- One method to get references from the online citation libraries.
     There has to be one entity for each item to be referenced. 
     An alternate method (rfc include) is described in the references. -->

<!ENTITY RFC2119 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY RFC5246 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5246.xml">
<!ENTITY RFC4346 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4346.xml">
<!ENTITY RFC2246 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2246.xml">
]>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<!-- used by XSLT processors -->
<!-- For a complete list and description of processing instructions (PIs), 
     please see http://xml.resource.org/authoring/README.html. -->
<!-- Below are generally applicable Processing Instructions (PIs) that most I-Ds might want to use.
     (Here they are set differently than their defaults in xml2rfc v1.32) -->
<?rfc strict="yes" ?>
<!-- give errors regarding ID-nits and DTD validation -->
<!-- control the table of contents (ToC) -->
<?rfc toc="yes"?>
<!-- generate a ToC -->
<?rfc tocdepth="4"?>
<!-- the number of levels of subsections in ToC. default: 3 -->
<!-- control references -->
<?rfc symrefs="yes"?>
<!-- use symbolic references tags, i.e, [RFC2119] instead of [1] -->
<?rfc sortrefs="yes" ?>
<!-- sort the reference entries alphabetically -->
<!-- control vertical white space 
     (using these PIs as follows is recommended by the RFC Editor) -->
<?rfc compact="yes" ?>
<!-- do not start each main section on a new page -->
<?rfc subcompact="no" ?>
<!-- keep one blank line between list items -->
<!-- end of list of popular I-D processing instructions -->
<rfc category="std" docName="draft-ietf-tls-prohibiting-rc4-00" ipr="trust200902" 
  updates="5246,4346,2246">
  <!-- category values: std, bcp, info, exp, and historic
     ipr values: full3667, noModification3667, noDerivatives3667
     you can add the attributes updates="NNNN" and obsoletes="NNNN" 
     they will automatically be output with "(if approved)" -->

  <!-- ***** FRONT MATTER ***** -->

  <front>
    <!-- The abbreviated title is used in the page header - it is only necessary if the 
         full title is longer than 39 characters -->

    <title>Prohibiting RC4 Cipher Suites</title>

    <!-- add 'role="editor"' below for the editors if appropriate -->

    <!-- Another author who claims to be an editor -->

    <author fullname="Andrei Popov" initials="A."
            surname="Popov">
      <organization>Microsoft Corp.</organization>

      <address>
        <postal>
          <street>One Microsoft Way</street>

          <!-- Reorder these if your country does things differently -->

          <city>Redmond</city>

          <region>WA</region>

          <code>98052</code>

          <country>USA</country>
        </postal>

        <email>andreipo@microsoft.com</email>

        <!-- uri and facsimile elements may also be added -->
      </address>
    </author>

    <date year="2014" />

    <!-- If the month and year are both specified and are the current ones, xml2rfc will fill 
         in the current day for you. If only the current year is specified, xml2rfc will fill 
	 in the current day and month for you. If the year is not the current one, it is 
	 necessary to specify at least a month (xml2rfc assumes day="1" if not specified for the 
	 purpose of calculating the expiry date).  With drafts it is normally sufficient to 
	 specify just the year. -->

    <!-- Meta-data Declarations -->

    <area>General</area>

    <workgroup>Internet Engineering Task Force</workgroup>

    <!-- WG name at the upperleft corner of the doc,
         IETF is fine for individual submissions.  
	 If this element is not present, the default is "Network Working Group",
         which is used by the RFC Editor as a nod to the history of the IETF. -->

    <keyword>draft</keyword>

    <!-- Keywords will be incorporated into HTML output
         files in a meta tag but they have no effect on text or nroff
         output. If you submit your draft to the RFC Editor, the
         keywords will be used for the search engine. -->

    <abstract>
      <t>This document requires that Transport Layer Security (TLS) clients and servers 
      never negotiate the use of RC4 cipher suites when they establish connections.</t>
    </abstract>
  </front>

  <middle>
    <section anchor="Introduction" title="Introduction">
      <t>RC4 is a stream cipher described in <xref target="SCH" />, which is widely 
      supported, and often preferred, by TLS servers. However, RC4 has long been known 
      to have a variety of cryptographic weaknesses, e.g. <xref target="PAU" />, 
      <xref target="MAN" />, <xref target="FLU" />. Recent cryptanalysis results 
      <xref target="ALF" /> exploit biases in the RC4 keystream to recover repeatedly 
      encrypted plaintexts.</t>

      <t>These recent results are on the verge of becoming practically exploitable; 
      currently they require 2^26 sessions or 13x2^30 encryptions. As a result, RC4 can 
      no longer be seen as providing a sufficient level of security for TLS sessions.</t>

      <t>This document requires that TLS (<xref target="RFC5246" />, 
      <xref target="RFC4346" />, <xref target="RFC2246" />) clients and servers never 
      negotiate the use of RC4 cipher suites.</t>

      <section title="Requirements Language">
        <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>

    <section title="Changes to TLS">
      <t>Because of the deficiencies noted in <xref target="Introduction" />:</t>

      <t>
        <list style="symbols">
          <t>TLS clients MUST NOT include RC4 cipher suites in the ClientHello message.</t>

          <t>TLS servers MUST NOT select an RC4 cipher suite when a TLS client sends such a 
          cipher suite in the ClientHello message.</t>

          <t>If the TLS client only offers RC4 cipher suites, the TLS server MUST terminate 
          the handshake. The TLS server MAY send the insufficient_security fatal alert in this 
          case.</t>
        </list>
      </t>

      <t><xref target="app-rc4-cipher-suites" /> lists the RC4 cipher suites defined for 
      TLS.</t>
    </section>

    <section anchor="Acknowledgements" title="Acknowledgements">
      <t>This document was inspired by discussions with Magnus Nystrom, Eric Rescorla, Joseph 
      Salowey, Yaron Sheffer, Nagendra Modadugu and others on the TLS mailing list.</t>

    </section>

    <!-- Possibly a 'Contributors' section ... -->

    <section anchor="IANA" title="IANA Considerations">
      <t>This memo includes no request to IANA.</t>

    </section>

    <section anchor="Security" title="Security Considerations">
      <t>This document helps maintain the security guarantees of the TLS protocol by prohibiting 
      the use of the RC4-based cipher suites (listed in <xref target="app-rc4-cipher-suites" />), 
      which do not provide a sufficiently high level of security.</t>
    </section>
  </middle>

  <!--  *****BACK MATTER ***** -->

  <back>
    <!-- References split into informative and normative -->

    <!-- There are 2 ways to insert reference entries from the citation libraries:
     1. define an ENTITY at the top, and use "ampersand character"RFC2629; here (as shown)
     2. simply use a PI "less than character"?rfc include="reference.RFC.2119.xml"?> here
        (for I-Ds: include="reference.I-D.narten-iana-considerations-rfc2434bis.xml")

     Both are cited textually in the same manner: by using xref elements.
     If you use the PI option, xml2rfc will, by default, try to find included files in the same
     directory as the including file. You can also define the XML_LIBRARY environment variable
     with a value containing a set of directories to search.  These can be either in the local
     filing system or remote ones accessed by http (http://domain/dir/... ).-->

    <references title="Normative References">
      <!--?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml"?-->
      &RFC2119;

      &RFC5246;

      &RFC4346;

      &RFC2246;

    </references>

    <references title="Informative References">
      <!-- Here we use entities that we defined at the beginning. -->

      <reference anchor="PAU">
        <front>
          <title>Permutation after RC4 Key Scheduling Reveals the Secret Key. In Proceedings of 
          the 14th Workshop on Selected Areas in Cryptography (SAC), pp. 360-377, vol. 4876, 
          LNCS, Springer.</title>

          <author initials="G." surname="Paul">
            <organization></organization>
          </author>
          <author initials="S." surname="Maitra">
            <organization></organization>
          </author>

          <date year="2007" />
        </front>
      </reference>

      <reference anchor="MAN">
        <front>
          <title>A Practical Attack on Broadcast RC4. FSE, pp. 152-164.</title>

          <author initials="I." surname="Mantin">
            <organization></organization>
          </author>
          <author initials="A." surname="Shamir">
            <organization></organization>
          </author>

          <date year="2001" />
        </front>
      </reference>

      <reference anchor="FLU">
        <front>
          <title>Weaknesses in the Key Scheduling Algorithm of RC4. Selected Areas in Cryptography, 
          pp. 1-24</title>

          <author initials="S. R." surname="Fluhrer">
            <organization></organization>
          </author>
          <author initials="I." surname="Mantin">
            <organization></organization>
          </author>
          <author initials="A." surname="Shamir">
            <organization></organization>
          </author>

          <date year="2001" />
        </front>
      </reference>

      <reference anchor="ALF" target="https://www.usenix.org/conference/usenixsecurity13/security-rc4-tls">
        <front>
          <title>On the security of RC4 in TLS and WPA. USENIX Security Symposium.</title>

          <author initials="N. J." surname="AlFardan">
            <organization></organization>
          </author>
          <author initials="D. J." surname="Bernstein">
            <organization></organization>
          </author>
          <author initials="K. G." surname="Paterson">
            <organization></organization>
          </author>
          <author initials="B." surname="Poettering">
            <organization></organization>
          </author>
          <author initials="J. C. N." surname="Schuldt">
            <organization></organization>
          </author>

          <date year="2013" />
        </front>
      </reference>

      <reference anchor="SCH">
        <front>
          <title>Applied Cryptography: Protocols, Algorithms, and Source Code in C, 2nd ed.</title>

          <author initials="B." surname="Schneier">
            <organization></organization>
          </author>

          <date year="1996" />
        </front>
      </reference>

    </references>

    <section anchor="app-rc4-cipher-suites" title="RC4 Cipher Suites">
      <t>The following cipher suites defined for TLS use RC4:</t>

      <t>
        <list style="symbols">

          <t>TLS_RSA_EXPORT_WITH_RC4_40_MD5></t>

          <t>TLS_RSA_WITH_RC4_128_MD5</t>

          <t>TLS_RSA_WITH_RC4_128_SHA</t>

          <t>TLS_DH_anon_EXPORT_WITH_RC4_40_MD5</t>

          <t>TLS_DH_anon_WITH_RC4_128_MD5</t>

          <t>TLS_KRB5_WITH_RC4_128_SHA></t>

          <t>TLS_KRB5_WITH_RC4_128_MD5></t>

          <t>TLS_KRB5_EXPORT_WITH_RC4_40_SHA</t>

          <t>TLS_KRB5_EXPORT_WITH_RC4_40_MD5</t>

          <t>TLS_PSK_WITH_RC4_128_SHA</t>

          <t>TLS_DHE_PSK_WITH_RC4_128_SHA</t>

          <t>TLS_RSA_PSK_WITH_RC4_128_SHA</t>

          <t>TLS_ECDH_ECDSA_WITH_RC4_128_SHA</t>

          <t>TLS_ECDHE_ECDSA_WITH_RC4_128_SHA</t>

          <t>TLS_ECDH_RSA_WITH_RC4_128_SHA</t>

          <t>TLS_ECDHE_RSA_WITH_RC4_128_SHA</t>

          <t>TLS_ECDH_anon_WITH_RC4_128_SHA</t>

          <t>TLS_ECDHE_PSK_WITH_RC4_128_SHA</t>

        </list>
      </t>
    </section>

    <!-- Change Log

v00 2013-08-15  AP  Initial version> -->

  </back>
</rfc>
