<?xml version="1.0"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY RFC5246 SYSTEM 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.5246.xml'>
<!ENTITY RFC6347 SYSTEM 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.6347.xml'>
<!ENTITY RFC4492 SYSTEM 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4492.xml'>
<!ENTITY RFC5489 SYSTEM 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.5489.xml'>
<!ENTITY RFC5116 SYSTEM 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.5116.xml'>
<!ENTITY RFC7539 SYSTEM 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.7539.xml'>
]>

<?rfc compact="no"?>
<?rfc toc="yes"?>
<?rfc symrefs="yes"?>

<rfc category="std" ipr="trust200902"
    updates="5246, 6347"  docName="draft-ietf-tls-chacha20-poly1305-04">

  <front>

    <title abbrev="chacha-tls">
       ChaCha20-Poly1305 Cipher Suites for Transport Layer Security (TLS)
    </title>

    <author initials="A." surname="Langley" fullname="Adam Langley">
      <organization>Google Inc</organization>
      <address>
        <email>agl@google.com</email>
      </address>
    </author>

    <author initials="W." surname="Chang" fullname="Wan-Teh Chang">
      <organization>Google Inc</organization>
      <address>
        <email>wtc@google.com</email>
      </address>
    </author>

    <author initials="N." surname="Mavrogiannopoulos"
            fullname="Nikos Mavrogiannopoulos">
      <organization>Red Hat</organization>
      <address>
        <email>nmav@redhat.com</email>
      </address>
    </author>

    <author initials="J." surname="Strombergson"
            fullname="Joachim Strombergson">
      <organization>Secworks Sweden AB</organization>
      <address>
        <email>joachim@secworks.se</email>
        <uri>http://secworks.se/</uri>
      </address>
    </author>

    <author initials="S." surname="Josefsson"
           fullname="Simon Josefsson">
      <organization>SJD AB</organization>
      <address>
        <email>simon@josefsson.org</email>
        <uri>http://josefsson.org/</uri>
      </address>
    </author>


    <date month="December" year="2015"/>

    <abstract>

      <t>This document describes the use of the ChaCha stream cipher
      and Poly1305 authenticator in the Transport Layer Security (TLS) and Datagram
      Transport Layer Security (DTLS) protocols.</t>

    </abstract>
  </front>

  <middle>

    <section anchor="intro"
             title="Introduction">

      <t>This document describes the use of the ChaCha stream cipher and Poly1305 authenticator
      in version 1.2 or later of the the Transport Layer Security (TLS) <xref target="RFC5246"/>
      protocol, as well as version 1.2 or later of the Datagram Transport Layer Security (DTLS)
      protocol <xref target="RFC6347"/>.</t>

      <t><xref target="CHACHA">ChaCha</xref> is a stream cipher developed by D. J. Bernstein in 2008. It is a refinement of Salsa20, which is one of the selected ciphers in the eSTREAM portfolio <xref target="ESTREAM"/>, and was used as the core of the SHA-3 finalist, BLAKE.</t>

      <t>The variant of ChaCha used in this document has 20 rounds, a 96-bit nonce and a 256-bit key, and will
      be referred to as ChaCha20.
      This is the conservative variant (with respect to security) of
      the ChaCha family and is described in <xref target="RFC7539"/>.</t>

      <t>
        <xref target="POLY1305">Poly1305</xref> is a Wegman-Carter, one-time authenticator
        designed by D. J. Bernstein. Poly1305 takes a 256-bit, one-time key and a message,
        and produces a 16-byte tag that authenticates the message such that an attacker has
        a negligible chance of producing a valid tag for an inauthentic message.
        It is also described in <xref target="RFC7539"/>.
      </t>

      <t>ChaCha and Poly1305
      have both been designed for high performance in software
      implementations. They typically admit a compact implementation that uses
      few resources and inexpensive operations, which makes them suitable
      on a wide range of architectures. They have also
      been designed to minimize leakage of information through side
      channels.</t>

      <t>Recent attacks <xref target="CBC-ATTACK"/> have indicated
      problems with the CBC-mode cipher suites in TLS and DTLS, as well as
      issues with the only supported stream cipher (RC4) <xref
      target="RC4-ATTACK"/>. While the existing AEAD cipher suites (based on AES-GCM)
      address some of these issues, there are concerns about their performance and ease of software
      implementation.
      </t>

      <t>Therefore, a new stream cipher to replace RC4 and address all the
      previous issues is needed. It is the purpose of this document to describe
      a secure stream cipher for both TLS and DTLS that is comparable to RC4 in
      speed on a wide range of platforms and can be implemented easily
      without being vulnerable to software side-channel attacks.</t>
    </section>

    <section anchor="chacha20suites"
             title="ChaCha20 Cipher Suites">
      <t>
        The ChaCha20 and Poly1305 primitives are built into an <xref
          target="RFC5116">AEAD algorithm</xref>, AEAD_CHACHA20_POLY1305, as
        described in <xref target="RFC7539"/>. This AEAD is incorporated into TLS and DTLS as specified in section 6.2.3.3 of <xref target="RFC5246"/>.
      </t>

      <t>AEAD_CHACHA20_POLY1305 requires a 96-bit nonce, which is formed as follows:

      <list style="numbers">
        <t>The 64-bit record sequence number is serialized as an 8-byte, big-endian value and padded on the left with four 0x00 bytes.</t>
        <t>The padded sequence number is XORed with the client_write_IV (when the client is sending) or server_write_IV (when the server is sending).</t>
      </list>
      </t>

      <t>
        In DTLS, the 64-bit seq_num is the 16-bit epoch concatenated with the 48-bit seq_num.
      </t>

      <t>
        This nonce construction is different from the one used with AES-GCM in
        TLS 1.2 but matches the scheme expected to be used in TLS 1.3. The
        nonce is constructed from the record sequence number and shared secret,
        both of which are known to the recipient. The advantage is that no
        per-record, explicit nonce need be transmitted, which saves eight bytes
        per record and prevents implementations from mistakenly using a random
        nonce. Thus, in the terms of <xref target="RFC5246"/>,
        SecurityParameters.fixed_iv_length is twelve bytes and
        SecurityParameters.record_iv_length is zero bytes.
      </t>

      <t>The following cipher suites are defined.</t>
      <figure>
        <artwork><![CDATA[
  TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256   = {0xTBD, 0xTBD}
  TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256 = {0xTBD, 0xTBD}
  TLS_DHE_RSA_WITH_CHACHA20_POLY1305_SHA256     = {0xTBD, 0xTBD}

  TLS_PSK_WITH_CHACHA20_POLY1305_SHA256         = {0xTBD, 0xTBD}
  TLS_ECDHE_PSK_WITH_CHACHA20_POLY1305_SHA256   = {0xTBD, 0xTBD}
  TLS_DHE_PSK_WITH_CHACHA20_POLY1305_SHA256     = {0xTBD, 0xTBD}
  TLS_RSA_PSK_WITH_CHACHA20_POLY1305_SHA256     = {0xTBD, 0xTBD}
]]></artwork>
      </figure>

      <t>The DHE_RSA, ECDHE_RSA, ECDHE_ECDSA, PSK,
      ECDHE_PSK, DHE_PSK and RSA_PSK key exchanges for these cipher suites are unaltered and thus are performed as defined in
      <xref target="RFC5246"/>, <xref target="RFC4492"/>, and <xref
      target="RFC5489"/>.</t>

      <t>The pseudorandom function (PRF) for all the cipher suites defined in this document is the TLS PRF with SHA-256 as the hash function.</t>
    </section>

    <section anchor="iana" title="IANA Considerations">

      <t>
        IANA is requested to add the following entries in the TLS Cipher Suite Registry:
      </t>

      <figure>
        <artwork><![CDATA[
  TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256   = {0xTBD, 0xTBD} {0xCC, 0xA8}
  TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256 = {0xTBD, 0xTBD} {0xCC, 0xA9}
  TLS_DHE_RSA_WITH_CHACHA20_POLY1305_SHA256     = {0xTBD, 0xTBD} {0xCC, 0xAA}

  TLS_PSK_WITH_CHACHA20_POLY1305_SHA256         = {0xTBD, 0xTBD} {0xCC, 0xAB}
  TLS_ECDHE_PSK_WITH_CHACHA20_POLY1305_SHA256   = {0xTBD, 0xTBD} {0xCC, 0xAC}
  TLS_DHE_PSK_WITH_CHACHA20_POLY1305_SHA256     = {0xTBD, 0xTBD} {0xCC, 0xAD}
  TLS_RSA_PSK_WITH_CHACHA20_POLY1305_SHA256     = {0xTBD, 0xTBD} {0xCC, 0xAE}
]]></artwork>
      </figure>

      <t>The cipher suite numbers listed in the second column are numbers used
        for cipher suite interoperability testing and it's suggested that IANA use these values for assignment.</t>
    </section>

    <section anchor="security"
             title="Security Considerations">

      <t>ChaCha20 follows the same basic principle as Salsa20<xref target="SALSA20SPEC"/>, a cipher
      with significant security review <xref target="SALSA20-SECURITY"/><xref target="ESTREAM"/>.
      At the time of writing this document, there are no known significant
      security problems with either cipher, and ChaCha20 is shown to be more
      resistant in certain attacks than Salsa20 <xref target="SALSA20-ATTACK"/>.
      Furthermore, ChaCha20 was used as the core of the BLAKE hash function,
      a SHA3 finalist, that has received considerable cryptanalytic
      attention <xref target="NIST-SHA3"/>.
      </t>

      <t>
        Poly1305 is designed to ensure that forged messages are rejected with a
        probability of 1-(n/2^107), where n is the maximum length of the input
        to Poly1305. In the case of (D)TLS, this means a maximum forgery
        probability of about 1 in 2^93.
      </t>

      <t>
        The cipher suites described in this document require that a nonce
        is never repeated under the same key. The design presented ensures
        this by using the TLS sequence number, which is unique and does not
        wrap <xref target="RFC5246"/>.
      </t>

      <t>
        It should be noted that AEADs, such as ChaCha20-Poly1305, are not
        intended to hide the lengths of plaintexts. When this document speaks of
        side-channel attacks, it is not considering traffic analysis, but
        rather timing and cache side-channels. Traffic analysis, while a valid
        concern, is outside the scope of the AEAD and is being addressed
        elsewhere in future versions of TLS.
      </t>

      <t>
        Otherwise, this document should not introduce any additional security
        considerations other than those that follow from the use of the
        AEAD_CHACHA20_POLY1305 construction, thus the reader is directed to the
        Security Considerations section of <xref target="RFC7539"/>.
      </t>
    </section>

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

      <t>The authors would like to thank Zooko Wilcox-OHearn, Samuel Neves and Colm MacCárthaigh for their suggestions and guidance.</t>

    </section>
  </middle>

  <back>

    <references title="Normative References">

      &RFC4492;
      &RFC5246;
      &RFC5489;
      &RFC6347;

      &RFC7539;


    </references>

    <references title="Informative References">

      <reference anchor="CHACHA" target="http://cr.yp.to/chacha/chacha-20080128.pdf">
        <front>
          <title>ChaCha, a variant of Salsa20</title>
          <author initials="D.J." surname="Bernstein"
                  fullname="D.J. Bernstein"/>
          <date month="January" year="2008" />
        </front>
      </reference>

      <reference anchor="POLY1305" target="http://cr.yp.to/mac/poly1305-20050329.pdf">
        <front>
          <title>The Poly1305-AES message-authentication code.</title>
          <author initials="D. J." surname="Bernstein"></author>
          <date month="March" year="2005"/>
        </front>
      </reference>

      &RFC5116;

      <reference anchor="SALSA20SPEC" target="http://cr.yp.to/snuffle/spec.pdf">
        <front>
          <title>Salsa20 specification</title>
          <author initials="D.J." surname="Bernstein"
                  fullname="D.J. Bernstein"/>
          <date month="April" year="2005" />
        </front>
      </reference>

      <reference anchor="SALSA20-SECURITY" target="http://cr.yp.to/snuffle/security.pdf">
        <front>
          <title>Salsa20 security</title>
          <author initials="D.J." surname="Bernstein"
                  fullname="D.J. Bernstein"/>
          <date month="April" year="2005" />
        </front>
      </reference>

      <reference anchor="ESTREAM" target="http://www.ecrypt.eu.org/stream/finallist.html">
        <front>
          <title>The eSTREAM Portfolio (rev. 1)</title>
          <author initials="S." surname="Babbage"
                  fullname="Steve Babbage"/>
          <author initials="C." surname="DeCanniere"
                  fullname="Christophe De Canniere"/>
          <author initials="A." surname="Cantenaut"
                  fullname="Anne Cantenaut"/>
          <author initials="C." surname="Cid"
                  fullname="Carlos Cid"/>
          <author initials="H." surname="Gilbert"
                  fullname="Henri Gilbert"/>
          <author initials="T." surname="Johansson"
                  fullname="Thomas Johansson"/>
          <author initials="M." surname="Parker"
                  fullname="Matthew Parker"/>
          <author initials="B." surname="Preneel"
                  fullname="Bart Preneel"/>
          <author initials="V." surname="Rijmen"
                  fullname="Vincent Rijmen"/>
          <author initials="M." surname="Robshaw"
                  fullname="Matthew Robshaw"/>
          <date month="September" year="2008" />
        </front>
      </reference>

      <reference anchor="CBC-ATTACK">
        <front>
          <title>Lucky Thirteen: Breaking the
          TLS and DTLS Record Protocols</title>
          <author initials="N.J." surname="AlFardan"
                  fullname="Nadhem J. AlFardan"/>
          <author initials="K." surname="Paterson"
                  fullname="K. Paterson"/>
          <date year="2013" />
        </front>
        <seriesInfo name="IEEE Symposium on Security and Privacy" value=""/>
      </reference>

      <reference anchor="RC4-ATTACK">
        <front>
          <title>Full Plaintext Recovery Attack on Broadcast RC4</title>
          <author initials="T." surname="Isobe"
                  fullname="Takanori Isobe"/>
          <author initials="T." surname="Ohigashi"
                  fullname="Toshihiro Ohigashi"/>
          <author initials="Y." surname="Watanabe"
                  fullname="Yuhei Watanabe"/>
          <author initials="M." surname="Morii"
                  fullname="Masakatu Morii"/>
          <date year="2013" />
        </front>
        <seriesInfo name="International Workshop on Fast Software Encryption" value=""/>
      </reference>

      <reference anchor="SALSA20-ATTACK" target="http://eprint.iacr.org/2007/472.pdf">
        <front>
          <title>New Features of Latin Dances: Analysis of Salsa, ChaCha, and Rumba</title>
          <author initials="J-P." surname="Aumasson"
                  fullname="Jean-Philippe Aumasson"/>
          <author initials="S." surname="Fischer"
                  fullname="Simon Fischer"/>
          <author initials="S." surname="Khazaei"
                  fullname="Shahram Khazaei"/>
          <author initials="W." surname="Meier"
                  fullname="Willi Meier"/>
          <author initials="C." surname="Rechberger"
                  fullname="Christian Rechberger"/>
          <date year="2007" />
        </front>
      </reference>

      <reference anchor="NIST-SHA3" target="http://dx.doi.org/10.6028/NIST.IR.7896">
        <front>
          <title>Third-Round Report of the SHA-3
          Cryptographic Hash Algorithm Competition</title>
          <author initials="S." surname="Chang"
                  fullname="Shu-jen Chang"/>
          <author initials="W." surname="Burr"
                  fullname="William E. Burr"/>
          <author initials="J." surname="Kelsey"
                  fullname="John M. Kelsey"/>
          <author initials="S." surname="Paul"
                  fullname="Souradyuti Paul"/>
          <author initials="L." surname="Bassham"
                  fullname="Lawrence E. Bassham"/>
          <date year="2012" />
        </front>
      </reference>

<!--      <reference anchor="KEY-RECOVERY-MAC">
        <front>
          <title>Key-recovery attacks on universal hash function based
          MAC algorithms.</title>
          <author initials="H." surname="Handschuh"
                  fullname="Helena Handschuh"/>
          <author initials="B." surname="Preneel"
                  fullname="Bart Preneel"/>
          <date year="2008" />
        </front>
      </reference>-->

    </references>


  </back>

</rfc>
