idnits 2.17.1 draft-ietf-tls-chacha20-poly1305-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- -- The draft header indicates that this document updates RFC6347, but the abstract doesn't seem to mention this, which it should. -- The draft header indicates that this document updates RFC5246, but the abstract doesn't seem to mention this, which it should. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year (Using the creation date from RFC5246, updated by this document, for RFC5378 checks: 2006-03-02) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (June 11, 2015) is 3242 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Looks like a reference, but probably isn't: '4' on line 131 -- Looks like a reference, but probably isn't: '8' on line 132 ** Obsolete normative reference: RFC 4492 (Obsoleted by RFC 8422) ** Obsolete normative reference: RFC 5246 (Obsoleted by RFC 8446) ** Downref: Normative reference to an Informational RFC: RFC 5489 ** Obsolete normative reference: RFC 6347 (Obsoleted by RFC 9147) ** Obsolete normative reference: RFC 7539 (Obsoleted by RFC 8439) Summary: 5 errors (**), 0 flaws (~~), 1 warning (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group A. Langley 3 Internet-Draft W. Chang 4 Updates: 5246, 6347 (if approved) Google Inc 5 Intended status: Standards Track N. Mavrogiannopoulos 6 Expires: December 13, 2015 Red Hat 7 J. Strombergson 8 Secworks Sweden AB 9 S. Josefsson 10 SJD AB 11 June 11, 2015 13 The ChaCha20-Poly1305 AEAD Cipher for Transport Layer Security 14 draft-ietf-tls-chacha20-poly1305-00 16 Abstract 18 This document describes the use of the ChaCha stream cipher with 19 Poly1305 in Transport Layer Security (TLS) and Datagram Transport 20 Layer Security (DTLS) protocols. 22 Status of This Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at http://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on December 13, 2015. 39 Copyright Notice 41 Copyright (c) 2015 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (http://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. Code Components extracted from this document must 50 include Simplified BSD License text as described in Section 4.e of 51 the Trust Legal Provisions and are provided without warranty as 52 described in the Simplified BSD License. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 57 2. The ChaCha Cipher . . . . . . . . . . . . . . . . . . . . . . 3 58 3. The Poly1305 Authenticator . . . . . . . . . . . . . . . . . 3 59 4. ChaCha20 Cipher Suites . . . . . . . . . . . . . . . . . . . 3 60 4.1. ChaCha20 Cipher Suites with Poly1305 . . . . . . . . . . 4 61 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 4 62 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4 63 7. Security Considerations . . . . . . . . . . . . . . . . . . . 5 64 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 5 65 8.1. Normative References . . . . . . . . . . . . . . . . . . 5 66 8.2. Informative References . . . . . . . . . . . . . . . . . 6 67 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7 69 1. Introduction 71 This document describes the use of the ChaCha stream cipher in the 72 Transport Layer Security (TLS) version 1.2 [RFC5246] protocol, as 73 well as in the Datagram Transport Layer Security (DTLS) version 1.2 74 [RFC6347], or any later versions. 76 ChaCha [CHACHA] is a stream cipher that has been designed for high 77 performance in software implementations. The cipher has compact 78 implementation and uses few resources and inexpensive operations that 79 makes it suitable for implementation on a wide range of 80 architectures. It has been designed to prevent leakage of 81 information through side channel analysis, has a simple and fast key 82 setup and provides good overall performance. It is a variant of 83 Salsa20 [SALSA20SPEC] which is one of the selected ciphers in the 84 eSTREAM portfolio [ESTREAM]. 86 Recent attacks [CBC-ATTACK] have indicated problems with CBC-mode 87 cipher suites in TLS and DTLS as well as issues with the only 88 supported stream cipher (RC4) [RC4-ATTACK]. While the existing AEAD 89 (AES-GCM) ciphersuites address some of these issues, concerns about 90 the performance and ease of software implementation are sometimes 91 raised. 93 Therefore, a new stream cipher to replace RC4 and address all the 94 previous issues is needed. It is the purpose of this document to 95 describe a secure stream cipher for both TLS and DTLS that is 96 comparable to RC4 in speed on a wide range of platforms and can be 97 implemented easily without being vulnerable to software side-channel 98 attacks. 100 2. The ChaCha Cipher 102 ChaCha [CHACHA] is a stream cipher developed by D. J. Bernstein in 103 2008. It is a refinement of Salsa20 and was used as the core of the 104 SHA-3 finalist, BLAKE. 106 The variant of ChaCha used in this document is ChaCha with 20 rounds, 107 a 96-bit nonce and a 256 bit key, which will be referred to as 108 ChaCha20 in the rest of this document. This is the conservative 109 variant (with respect to security) of the ChaCha family and is 110 described in [RFC7539]. 112 3. The Poly1305 Authenticator 114 Poly1305 [POLY1305] is a Wegman-Carter, one-time authenticator 115 designed by D. J. Bernstein. Poly1305 takes a 32-byte, one-time 116 key and a message and produces a 16-byte tag that authenticates the 117 message such that an attacker has a negligible chance of producing a 118 valid tag for an inauthentic message. It is described in [RFC7539]. 120 4. ChaCha20 Cipher Suites 122 In the next sections different ciphersuites are defined that utilize 123 the ChaCha20 cipher combined with various message authentication 124 methods. 126 In all cases, the ChaCha20 cipher, as in [RFC7539], uses a 96-bit 127 nonce. That nonce is updated on the encryption of every TLS record, 128 and is formed as follows. 130 struct { 131 opaque salt[4]; 132 opaque record_counter[8]; 133 } ChaChaNonce; 135 The salt is generated as part of the handshake process. It is either 136 the client_write_IV (when the client is sending) or the 137 server_write_IV (when the server is sending). The salt length 138 (SecurityParameters.fixed_iv_length) is 4 bytes. The record_counter 139 is the 64-bit TLS record sequence number in network byte order. In 140 case of DTLS the record_counter is formed as the concatenation of the 141 16-bit epoch with the 48-bit sequence number. 143 In both TLS and DTLS the ChaChaNonce is implicit and not sent as part 144 of the packet. 146 The pseudorandom function (PRF) for TLS 1.2 is the TLS PRF with 147 SHA-256 as the hash function. 149 The DHE_RSA, ECDHE_RSA, ECDHE_ECDSA, PSK, ECDHE_PSK key exchanges are 150 performed as defined in [RFC5246], [RFC4492], and [RFC5489]. 152 4.1. ChaCha20 Cipher Suites with Poly1305 154 The ChaCha20 and Poly1305 primitives are built into an AEAD algorithm 155 [RFC5116], AEAD_CHACHA20_POLY1305, described in [RFC7539]. It takes 156 as input a 256-bit key and a 96-bit nonce, and outputs the ciphertext 157 and an 128-bit tag. 159 When used in TLS, the "record_iv_length" is zero and the nonce is set 160 to be the ChaChaNonce. The additional data is seq_num + 161 TLSCompressed.type + TLSCompressed.version + TLSCompressed.length, 162 where "+" denotes concatenation. The output tag is appended to the 163 ciphertext. 165 The following CipherSuites are defined. 167 TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305 = {0xTBD, 0xTBD} {0xCC, 0xA1} 168 TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305 = {0xTBD, 0xTBD} {0xCC, 0xA2} 169 TLS_DHE_RSA_WITH_CHACHA20_POLY1305 = {0xTBD, 0xTBD} {0xCC, 0xA3} 171 TLS_PSK_WITH_CHACHA20_POLY1305 = {0xTBD, 0xTBD} {0xCC, 0xA5} 172 TLS_ECDHE_PSK_WITH_CHACHA20_POLY1305 = {0xTBD, 0xTBD} {0xCC, 0xA6} 174 5. Acknowledgements 176 The authors would like to thank Zooko Wilcox-OHearn and Samuel Neves. 178 6. IANA Considerations 180 IANA is requested to assign the following Cipher Suites in the TLS 181 Cipher Suite Registry: 183 TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305 = {0xTBD, 0xTBD} {0xCC, 0xA1} 184 TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305 = {0xTBD, 0xTBD} {0xCC, 0xA2} 185 TLS_DHE_RSA_WITH_CHACHA20_POLY1305 = {0xTBD, 0xTBD} {0xCC, 0xA3} 187 TLS_PSK_WITH_CHACHA20_POLY1305 = {0xTBD, 0xTBD} {0xCC, 0xA5} 188 TLS_ECDHE_PSK_WITH_CHACHA20_POLY1305 = {0xTBD, 0xTBD} {0xCC, 0xA6} 190 The ciphersuite numbers listed on the last column are numbers used 191 for ciphersuite interoperability testing, and are the suggested to 192 IANA to assign. 194 7. Security Considerations 196 ChaCha20 follows the same basic principle as Salsa20, a cipher with 197 significant security review [SALSA20-SECURITY][ESTREAM]. At the time 198 of writing this document, there are no known significant security 199 problems with either cipher, and ChaCha20 is shown to be more 200 resistant in certain attacks than Salsa20 [SALSA20-ATTACK]. 201 Furthermore ChaCha20 was used as the core of the BLAKE hash function, 202 a SHA3 finalist, that had received considerable cryptanalytic 203 attention [NIST-SHA3]. 205 Poly1305 is designed to ensure that forged messages are rejected with 206 a probability of 1-(n/2^102) for a 16*n byte message, even after 207 sending 2^64 legitimate messages. 209 The cipher suites described in this document require that a nonce is 210 never repeated under the same key. The design presented ensures that 211 by using the TLS sequence number which is unique and does not wrap 212 [RFC5246]. 214 This document should not introduce any other security considerations 215 than those that directly follow from the use of the stream cipher 216 ChaCha20, the AEAD_CHACHA20_POLY1305 construction, (see also the 217 Security Considerations section of [RFC7539]). 219 8. References 221 8.1. Normative References 223 [RFC4492] Blake-Wilson, S., Bolyard, N., Gupta, V., Hawk, C., and B. 224 Moeller, "Elliptic Curve Cryptography (ECC) Cipher Suites 225 for Transport Layer Security (TLS)", RFC 4492, May 2006. 227 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 228 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 230 [RFC5489] Badra, M. and I. Hajjeh, "ECDHE_PSK Cipher Suites for 231 Transport Layer Security (TLS)", RFC 5489, March 2009. 233 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 234 Security Version 1.2", RFC 6347, January 2012. 236 [RFC7539] Nir, Y. and A. Langley, "ChaCha20 and Poly1305 for IETF 237 Protocols", RFC 7539, May 2015. 239 8.2. Informative References 241 [CHACHA] Bernstein, D., "ChaCha, a variant of Salsa20", January 242 2008, . 244 [POLY1305] 245 Bernstein, D., "The Poly1305-AES message-authentication 246 code.", March 2005, 247 . 249 [RFC5116] McGrew, D., "An Interface and Algorithms for Authenticated 250 Encryption", RFC 5116, January 2008. 252 [SALSA20SPEC] 253 Bernstein, D., "Salsa20 specification", April 2005, 254 . 256 [SALSA20-SECURITY] 257 Bernstein, D., "Salsa20 security", April 2005, 258 . 260 [ESTREAM] Babbage, S., DeCanniere, C., Cantenaut, A., Cid, C., 261 Gilbert, H., Johansson, T., Parker, M., Preneel, B., 262 Rijmen, V., and M. Robshaw, "The eSTREAM Portfolio (rev. 263 1)", September 2008, 264 . 266 [CBC-ATTACK] 267 AlFardan, N. and K. Paterson, "Lucky Thirteen: Breaking 268 the TLS and DTLS Record Protocols", IEEE Symposium on 269 Security and Privacy , 2013. 271 [RC4-ATTACK] 272 Isobe, T., Ohigashi, T., Watanabe, Y., and M. Morii, "Full 273 Plaintext Recovery Attack on Broadcast RC4", International 274 Workshop on Fast Software Encryption , 2013. 276 [SALSA20-ATTACK] 277 Aumasson, J-P., Fischer, S., Khazaei, S., Meier, W., and 278 C. Rechberger, "New Features of Latin Dances: Analysis of 279 Salsa, ChaCha, and Rumba", 2007, 280 . 282 [NIST-SHA3] 283 Chang, S., Burr, W., Kelsey, J., Paul, S., and L. Bassham, 284 "Third-Round Report of the SHA-3 Cryptographic Hash 285 Algorithm Competition", 2012, 286 . 288 Authors' Addresses 290 Adam Langley 291 Google Inc 293 Email: agl@google.com 295 Wan-Teh Chang 296 Google Inc 298 Email: wtc@google.com 300 Nikos Mavrogiannopoulos 301 Red Hat 303 Email: nmav@redhat.com 305 Joachim Strombergson 306 Secworks Sweden AB 308 Email: joachim@secworks.se 309 URI: http://secworks.se/ 311 Simon Josefsson 312 SJD AB 314 Email: simon@josefsson.org 315 URI: http://josefsson.org/