doc: Add RFC documents

1 files changed, 451 insertions, 0 deletions

diff --git a/doc/rfc/rfc7905.txt b/doc/rfc/rfc7905.txt
new file mode 100644
index 0000000..28cf423
--- /dev/null
+++ b/doc/rfc/rfc7905.txt
@@ -0,0 +1,451 @@
+
+
+
+
+
+
+Internet Engineering Task Force (IETF)                        A. Langley
+Request for Comments: 7905                                      W. Chang
+Updates: 5246, 6347                                         Google, Inc.
+Category: Standards Track                           N. Mavrogiannopoulos
+ISSN: 2070-1721                                                  Red Hat
+                                                         J. Strombergson
+                                                      Secworks Sweden AB
+                                                            S. Josefsson
+                                                                  SJD AB
+                                                               June 2016
+
+
+   ChaCha20-Poly1305 Cipher Suites for Transport Layer Security (TLS)
+
+Abstract
+
+   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.
+
+   This document updates RFCs 5246 and 6347.
+
+Status of This Memo
+
+   This is an Internet Standards Track document.
+
+   This document is a product of the Internet Engineering Task Force
+   (IETF).  It represents the consensus of the IETF community.  It has
+   received public review and has been approved for publication by the
+   Internet Engineering Steering Group (IESG).  Further information on
+   Internet Standards is available in Section 2 of RFC 7841.
+
+   Information about the current status of this document, any errata,
+   and how to provide feedback on it may be obtained at
+   http://www.rfc-editor.org/info/rfc7905.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Langley, et al.              Standards Track                    [Page 1]
+
+RFC 7905                 ChaCha-Poly1305 for TLS               June 2016
+
+
+Copyright Notice
+
+   Copyright (c) 2016 IETF Trust and the persons identified as the
+   document authors.  All rights reserved.
+
+   This document is subject to BCP 78 and the IETF Trust's Legal
+   Provisions Relating to IETF Documents
+   (http://trustee.ietf.org/license-info) in effect on the date of
+   publication of this document.  Please review these documents
+   carefully, as they describe your rights and restrictions with respect
+   to this document.  Code Components extracted from this document must
+   include Simplified BSD License text as described in Section 4.e of
+   the Trust Legal Provisions and are provided without warranty as
+   described in the Simplified BSD License.
+
+Table of Contents
+
+   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
+   2.  ChaCha20 Cipher Suites  . . . . . . . . . . . . . . . . . . .   4
+   3.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   5
+   4.  Security Considerations . . . . . . . . . . . . . . . . . . .   5
+   5.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   6
+     5.1.  Normative References  . . . . . . . . . . . . . . . . . .   6
+     5.2.  Informative References  . . . . . . . . . . . . . . . . .   6
+   Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . .   8
+   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   8
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Langley, et al.              Standards Track                    [Page 2]
+
+RFC 7905                 ChaCha-Poly1305 for TLS               June 2016
+
+
+1.  Introduction
+
+   This document describes the use of the ChaCha stream cipher and
+   Poly1305 authenticator in version 1.2 or later of the Transport Layer
+   Security (TLS) protocol [RFC5246] as well as version 1.2 or later of
+   the Datagram Transport Layer Security (DTLS) protocol [RFC6347].
+
+   ChaCha [CHACHA] 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 [ESTREAM], and it was used as the
+   core of the SHA-3 finalist, BLAKE.
+
+   The variant of ChaCha used in this document has 20 rounds, a 96-bit
+   nonce, and a 256-bit key; it is referred to as "ChaCha20".  This is
+   the conservative variant (with respect to security) of the ChaCha
+   family and is described in [RFC7539].
+
+   Poly1305 [POLY1305] is a Wegman-Carter, one-time authenticator
+   designed by D. J. Bernstein.  Poly1305 takes a 256-bit, one-time key
+   and a message, and it 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 described in [RFC7539].
+
+   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.
+
+   Recent attacks [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) [RC4-ATTACK].  While the existing
+   Authenticated Encryption with Associated Data (AEAD) cipher suites
+   (based on AES-GCM) address some of these issues, there are concerns
+   about their performance and ease of software implementation.
+
+   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.
+
+
+
+
+
+
+
+
+Langley, et al.              Standards Track                    [Page 3]
+
+RFC 7905                 ChaCha-Poly1305 for TLS               June 2016
+
+
+2.  ChaCha20 Cipher Suites
+
+   The ChaCha20 and Poly1305 primitives are built into an AEAD algorithm
+   [RFC5116], AEAD_CHACHA20_POLY1305, as described in [RFC7539].  This
+   AEAD is incorporated into TLS and DTLS as specified in
+   Section 6.2.3.3 of [RFC5246].
+
+   AEAD_CHACHA20_POLY1305 requires a 96-bit nonce, which is formed as
+   follows:
+
+   1.  The 64-bit record sequence number is serialized as an 8-byte,
+       big-endian value and padded on the left with four 0x00 bytes.
+
+   2.  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).
+
+   In DTLS, the 64-bit seq_num is the 16-bit epoch concatenated with the
+   48-bit sequence_number.
+
+   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 the
+   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 [RFC5246],
+   SecurityParameters.fixed_iv_length is twelve bytes and
+   SecurityParameters.record_iv_length is zero bytes.
+
+   The following cipher suites are defined:
+
+   TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256   = {0xCC, 0xA8}
+   TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256 = {0xCC, 0xA9}
+   TLS_DHE_RSA_WITH_CHACHA20_POLY1305_SHA256     = {0xCC, 0xAA}
+
+   TLS_PSK_WITH_CHACHA20_POLY1305_SHA256         = {0xCC, 0xAB}
+   TLS_ECDHE_PSK_WITH_CHACHA20_POLY1305_SHA256   = {0xCC, 0xAC}
+   TLS_DHE_PSK_WITH_CHACHA20_POLY1305_SHA256     = {0xCC, 0xAD}
+   TLS_RSA_PSK_WITH_CHACHA20_POLY1305_SHA256     = {0xCC, 0xAE}
+
+   The DHE_RSA, ECDHE_RSA, ECDHE_ECDSA, PSK, ECDHE_PSK, DHE_PSK, and
+   RSA_PSK key exchanges for these cipher suites are unaltered; thus,
+   they are performed as defined in [RFC5246], [RFC4492], and [RFC5489].
+
+   The pseudorandom function (PRF) for all the cipher suites defined in
+   this document is the TLS PRF with SHA-256 [FIPS180-4] as the hash
+   function.
+
+
+
+Langley, et al.              Standards Track                    [Page 4]
+
+RFC 7905                 ChaCha-Poly1305 for TLS               June 2016
+
+
+3.  IANA Considerations
+
+   IANA has added the following entries in the TLS Cipher Suite
+   Registry:
+
+   TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256   = {0xCC, 0xA8}
+   TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256 = {0xCC, 0xA9}
+   TLS_DHE_RSA_WITH_CHACHA20_POLY1305_SHA256     = {0xCC, 0xAA}
+
+   TLS_PSK_WITH_CHACHA20_POLY1305_SHA256         = {0xCC, 0xAB}
+   TLS_ECDHE_PSK_WITH_CHACHA20_POLY1305_SHA256   = {0xCC, 0xAC}
+   TLS_DHE_PSK_WITH_CHACHA20_POLY1305_SHA256     = {0xCC, 0xAD}
+   TLS_RSA_PSK_WITH_CHACHA20_POLY1305_SHA256     = {0xCC, 0xAE}
+
+4.  Security Considerations
+
+   ChaCha20 follows the same basic principle as Salsa20 [SALSA20SPEC], a
+   cipher with significant security review [SALSA20-SECURITY] [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 [SALSA20-ATTACK].
+   Furthermore, ChaCha20 was used as the core of the BLAKE hash
+   function, a SHA3 finalist, which has received considerable
+   cryptanalytic attention [NIST-SHA3].
+
+   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.
+
+   The cipher suites described in this document require that a nonce
+   never be repeated under the same key.  The design presented ensures
+   this by using the TLS sequence number, which is unique and does not
+   wrap [RFC5246].
+
+   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.
+
+   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 [RFC7539].
+
+
+
+
+
+Langley, et al.              Standards Track                    [Page 5]
+
+RFC 7905                 ChaCha-Poly1305 for TLS               June 2016
+
+
+5.  References
+
+5.1.  Normative References
+
+   [FIPS180-4]
+              National Institute of Standards and Technology, "Secure
+              Hash Standard (SHS)", FIPS PUB 180-4,
+              DOI 10.6028/NIST.FIPS180-4, August 2015,
+              <http://nvlpubs.nist.gov/nistpubs/FIPS/
+              NIST.FIPS.180-4.pdf>.
+
+   [RFC4492]  Blake-Wilson, S., Bolyard, N., Gupta, V., Hawk, C., and B.
+              Moeller, "Elliptic Curve Cryptography (ECC) Cipher Suites
+              for Transport Layer Security (TLS)", RFC 4492,
+              DOI 10.17487/RFC4492, May 2006,
+              <http://www.rfc-editor.org/info/rfc4492>.
+
+   [RFC5246]  Dierks, T. and E. Rescorla, "The Transport Layer Security
+              (TLS) Protocol Version 1.2", RFC 5246,
+              DOI 10.17487/RFC5246, August 2008,
+              <http://www.rfc-editor.org/info/rfc5246>.
+
+   [RFC5489]  Badra, M. and I. Hajjeh, "ECDHE_PSK Cipher Suites for
+              Transport Layer Security (TLS)", RFC 5489,
+              DOI 10.17487/RFC5489, March 2009,
+              <http://www.rfc-editor.org/info/rfc5489>.
+
+   [RFC6347]  Rescorla, E. and N. Modadugu, "Datagram Transport Layer
+              Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347,
+              January 2012, <http://www.rfc-editor.org/info/rfc6347>.
+
+   [RFC7539]  Nir, Y. and A. Langley, "ChaCha20 and Poly1305 for IETF
+              Protocols", RFC 7539, DOI 10.17487/RFC7539, May 2015,
+              <http://www.rfc-editor.org/info/rfc7539>.
+
+5.2.  Informative References
+
+   [CBC-ATTACK]
+              AlFardan, N. and K. Paterson, "Lucky Thirteen: Breaking
+              the TLS and DTLS Record Protocols", IEEE Symposium
+              on Security and Privacy, 2013,
+              <http://www.ieee-security.org/TC/SP2013/papers/
+              4977a526.pdf>.
+
+   [CHACHA]   Bernstein, D., "ChaCha, a variant of Salsa20", January
+              2008, <http://cr.yp.to/chacha/chacha-20080128.pdf>.
+
+
+
+
+
+Langley, et al.              Standards Track                    [Page 6]
+
+RFC 7905                 ChaCha-Poly1305 for TLS               June 2016
+
+
+   [ESTREAM]  Babbage, S., DeCanniere, C., Cantenaut, A., Cid, C.,
+              Gilbert, H., Johansson, T., Parker, M., Preneel, B.,
+              Rijmen, V., and M. Robshaw, "The eSTREAM Portfolio
+              (rev. 1)", September 2008,
+              <http://www.ecrypt.eu.org/stream/finallist.html>.
+
+   [NIST-SHA3]
+              Chang, S., Perlner, R., Burr, W., Turan, M., Kelsey, J.,
+              Paul, S., and L. Bassham, "Third-Round Report of the SHA-3
+              Cryptographic Hash Algorithm Competition",
+              DOI 10.6028/NIST.IR.7896, November 2012,
+              <http://dx.doi.org/10.6028/NIST.IR.7896>.
+
+   [POLY1305] Bernstein, D., "The Poly1305-AES message-authentication
+              code", FSE '05 Proceedings of the 12th international
+              conference on Fast Software Encryption Pages 32-49,
+              DOI 10.1007/11502760_3, February 2005,
+              <http://cr.yp.to/mac/poly1305-20050329.pdf>.
+
+   [RC4-ATTACK]
+              Isobe, T., Ohigashi, T., Watanabe, Y., and M. Morii, "Full
+              Plaintext Recovery Attack on Broadcast RC4", International
+              Workshop on Fast Software Encryption FSE,
+              DOI 10.1007/978-3-662-43933-3_10, 2013,
+              <http://www.iacr.org/archive/
+              fse2013/84240167/84240167.pdf>.
+
+   [RFC5116]  McGrew, D., "An Interface and Algorithms for Authenticated
+              Encryption", RFC 5116, DOI 10.17487/RFC5116, January 2008,
+              <http://www.rfc-editor.org/info/rfc5116>.
+
+   [SALSA20-ATTACK]
+              Aumasson, J-P., Fischer, S., Khazaei, S., Meier, W., and
+              C. Rechberger, "New Features of Latin Dances: Analysis of
+              Salsa, ChaCha, and Rumba",
+              DOI 10.1007/978-3-540-71039-4_30, 2007,
+              <http://eprint.iacr.org/2007/472.pdf>.
+
+   [SALSA20-SECURITY]
+              Bernstein, D., "Salsa20 security", April 2005,
+              <http://cr.yp.to/snuffle/security.pdf>.
+
+   [SALSA20SPEC]
+              Bernstein, D., "Salsa20 specification", April 2005,
+              <http://cr.yp.to/snuffle/spec.pdf>.
+
+
+
+
+
+
+Langley, et al.              Standards Track                    [Page 7]
+
+RFC 7905                 ChaCha-Poly1305 for TLS               June 2016
+
+
+Acknowledgements
+
+   The authors would like to thank Zooko Wilcox-O'Hearn, Samuel Neves,
+   and Colm MacCarthaigh for their suggestions and guidance.
+
+Authors' Addresses
+
+   Adam Langley
+   Google, Inc.
+
+   Email: agl@google.com
+
+
+   Wan-Teh Chang
+   Google, Inc.
+
+   Email: wtc@google.com
+
+
+   Nikos Mavrogiannopoulos
+   Red Hat
+
+   Email: nmav@redhat.com
+
+
+   Joachim Strombergson
+   Secworks Sweden AB
+
+   Email: joachim@secworks.se
+   URI:   http://secworks.se/
+
+
+   Simon Josefsson
+   SJD AB
+
+   Email: simon@josefsson.org
+   URI:   http://josefsson.org/
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Langley, et al.              Standards Track                    [Page 8]
+