From 4bfd864f10b68b71482b35c818559068ef8d5797 Mon Sep 17 00:00:00 2001 From: Thomas Voss Date: Wed, 27 Nov 2024 20:54:24 +0100 Subject: doc: Add RFC documents --- doc/rfc/rfc7905.txt | 451 ++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 451 insertions(+) create mode 100644 doc/rfc/rfc7905.txt (limited to 'doc/rfc/rfc7905.txt') 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, + . + + [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, + . + + [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security + (TLS) Protocol Version 1.2", RFC 5246, + DOI 10.17487/RFC5246, August 2008, + . + + [RFC5489] Badra, M. and I. Hajjeh, "ECDHE_PSK Cipher Suites for + Transport Layer Security (TLS)", RFC 5489, + DOI 10.17487/RFC5489, March 2009, + . + + [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer + Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, + January 2012, . + + [RFC7539] Nir, Y. and A. Langley, "ChaCha20 and Poly1305 for IETF + Protocols", RFC 7539, DOI 10.17487/RFC7539, May 2015, + . + +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, + . + + [CHACHA] Bernstein, D., "ChaCha, a variant of Salsa20", January + 2008, . + + + + + +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, + . + + [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, + . + + [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, + . + + [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, + . + + [RFC5116] McGrew, D., "An Interface and Algorithms for Authenticated + Encryption", RFC 5116, DOI 10.17487/RFC5116, January 2008, + . + + [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, + . + + [SALSA20-SECURITY] + Bernstein, D., "Salsa20 security", April 2005, + . + + [SALSA20SPEC] + Bernstein, D., "Salsa20 specification", April 2005, + . + + + + + + +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] + -- cgit v1.2.3