idnits 2.17.1 draft-mavrogiannopoulos-chacha-tls-05.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 (April 3, 2015) is 3303 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 133 -- Looks like a reference, but probably isn't: '8' on line 134 ** 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) ** Downref: Normative reference to an Informational draft: draft-irtf-cfrg-chacha20-poly1305 (ref. 'I-D.irtf-cfrg-chacha20-poly1305') 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: October 5, 2015 Red Hat 7 J. Strombergson 8 Secworks Sweden AB 9 S. Josefsson 10 SJD AB 11 April 3, 2015 13 The ChaCha Stream Cipher for Transport Layer Security 14 draft-mavrogiannopoulos-chacha-tls-05 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 October 5, 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 [I-D.irtf-cfrg-chacha20-poly1305]. 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 119 [I-D.irtf-cfrg-chacha20-poly1305]. 121 4. ChaCha20 Cipher Suites 123 In the next sections different ciphersuites are defined that utilize 124 the ChaCha20 cipher combined with various message authentication 125 methods. 127 In all cases, the ChaCha20 cipher, as in 128 [I-D.irtf-cfrg-chacha20-poly1305], uses a 96-bit nonce. That nonce 129 is updated on the encryption of every TLS record, and is formed as 130 follows. 132 struct { 133 opaque salt[4]; 134 opaque record_counter[8]; 135 } ChaChaNonce; 137 The salt is generated as part of the handshake process. It is either 138 the client_write_IV (when the client is sending) or the 139 server_write_IV (when the server is sending). The salt length 140 (SecurityParameters.fixed_iv_length) is 4 bytes. The record_counter 141 is the 64-bit TLS record sequence number. In case of DTLS the 142 record_counter is formed as the concatenation of the 16-bit epoch 143 with the 48-bit sequence number. 145 In both TLS and DTLS the ChaChaNonce is implicit and not sent as part 146 of the packet. 148 The pseudorandom function (PRF) for TLS 1.2 is the TLS PRF with 149 SHA-256 as the hash function. 151 The RSA, DHE_RSA, ECDHE_RSA, ECDHE_ECDSA, PSK, DHE_PSK, RSA_PSK, 152 ECDHE_PSK key exchanges are performed as defined in [RFC5246], 153 [RFC4492], and [RFC5489]. 155 4.1. ChaCha20 Cipher Suites with Poly1305 157 The ChaCha20 and Poly1305 primitives are built into an AEAD algorithm 158 [RFC5116], AEAD_CHACHA20_POLY1305, described in 159 [I-D.irtf-cfrg-chacha20-poly1305]. It takes as input a 256-bit key 160 and a 96-bit nonce. 162 When used in TLS, the "record_iv_length" is zero and the nonce is set 163 to be the ChaChaNonce. The additional data is seq_num + 164 TLSCompressed.type + TLSCompressed.version + TLSCompressed.length, 165 where "+" denotes concatenation. 167 The following CipherSuites are defined. 169 TLS_RSA_WITH_CHACHA20_POLY1305 = {0xTBD, 0xTBD} {0xCC, 0xA0} 170 TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305 = {0xTBD, 0xTBD} {0xCC, 0xA1} 171 TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305 = {0xTBD, 0xTBD} {0xCC, 0xA2} 173 TLS_DHE_RSA_WITH_CHACHA20_POLY1305 = {0xTBD, 0xTBD} {0xCC, 0xA3} 174 TLS_DHE_PSK_WITH_CHACHA20_POLY1305 = {0xTBD, 0xTBD} {0xCC, 0xA4} 176 TLS_PSK_WITH_CHACHA20_POLY1305 = {0xTBD, 0xTBD} {0xCC, 0xA5} 177 TLS_ECDHE_PSK_WITH_CHACHA20_POLY1305 = {0xTBD, 0xTBD} {0xCC, 0xA6} 178 TLS_RSA_PSK_WITH_CHACHA20_POLY1305 = {0xTBD, 0xTBD} {0xCC, 0xA7} 180 5. Acknowledgements 182 The authors would like to thank Zooko Wilcox-OHearn and Samuel Neves. 184 6. IANA Considerations 186 IANA is requested to assign the following Cipher Suites in the TLS 187 Cipher Suite Registry: 189 TLS_RSA_WITH_CHACHA20_POLY1305 = {0xTBD, 0xTBD} {0xCC, 0xA0} 190 TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305 = {0xTBD, 0xTBD} {0xCC, 0xA1} 191 TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305 = {0xTBD, 0xTBD} {0xCC, 0xA2} 193 TLS_DHE_RSA_WITH_CHACHA20_POLY1305 = {0xTBD, 0xTBD} {0xCC, 0xA3} 194 TLS_DHE_PSK_WITH_CHACHA20_POLY1305 = {0xTBD, 0xTBD} {0xCC, 0xA4} 196 TLS_PSK_WITH_CHACHA20_POLY1305 = {0xTBD, 0xTBD} {0xCC, 0xA5} 197 TLS_ECDHE_PSK_WITH_CHACHA20_POLY1305 = {0xTBD, 0xTBD} {0xCC, 0xA6} 198 TLS_RSA_PSK_WITH_CHACHA20_POLY1305 = {0xTBD, 0xTBD} {0xCC, 0xA7} 200 The ciphersuite numbers listed on the last column are numbers used 201 for ciphersuite interoperability testing, and are the suggested to 202 IANA to assign. 204 7. Security Considerations 206 ChaCha20 follows the same basic principle as Salsa20, a cipher with 207 significant security review [SALSA20-SECURITY][ESTREAM]. At the time 208 of writing this document, there are no known significant security 209 problems with either cipher, and ChaCha20 is shown to be more 210 resistant in certain attacks than Salsa20 [SALSA20-ATTACK]. 211 Furthermore ChaCha20 was used as the core of the BLAKE hash function, 212 a SHA3 finalist, that had received considerable cryptanalytic 213 attention [NIST-SHA3]. 215 Poly1305 is designed to ensure that forged messages are rejected with 216 a probability of 1-(n/2^102) for a 16*n byte message, even after 217 sending 2^64 legitimate messages. 219 The cipher suites described in this document require that a nonce is 220 never repeated under the same key. The design presented ensures that 221 by using the TLS sequence number which is unique and does not wrap 222 [RFC5246]. 224 This document should not introduce any other security considerations 225 than those that directly follow from the use of the stream cipher 226 ChaCha20, the AEAD_CHACHA20_POLY1305 construction, (see also the 227 Security Considerations section of 228 [I-D.irtf-cfrg-chacha20-poly1305]). 230 8. References 232 8.1. Normative References 234 [RFC4492] Blake-Wilson, S., Bolyard, N., Gupta, V., Hawk, C., and B. 235 Moeller, "Elliptic Curve Cryptography (ECC) Cipher Suites 236 for Transport Layer Security (TLS)", RFC 4492, May 2006. 238 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 239 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 241 [RFC5489] Badra, M. and I. Hajjeh, "ECDHE_PSK Cipher Suites for 242 Transport Layer Security (TLS)", RFC 5489, March 2009. 244 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 245 Security Version 1.2", RFC 6347, January 2012. 247 [I-D.irtf-cfrg-chacha20-poly1305] 248 Nir, Y. and A. Langley, "ChaCha20 and Poly1305 for IETF 249 protocols", draft-irtf-cfrg-chacha20-poly1305-10 (work in 250 progress), February 2015. 252 8.2. Informative References 254 [CHACHA] Bernstein, D., "ChaCha, a variant of Salsa20", January 255 2008, . 257 [POLY1305] 258 Bernstein, D., "The Poly1305-AES message-authentication 259 code.", March 2005, 260 . 262 [RFC5116] McGrew, D., "An Interface and Algorithms for Authenticated 263 Encryption", RFC 5116, January 2008. 265 [SALSA20SPEC] 266 Bernstein, D., "Salsa20 specification", April 2005, 267 . 269 [SALSA20-SECURITY] 270 Bernstein, D., "Salsa20 security", April 2005, 271 . 273 [ESTREAM] Babbage, S., DeCanniere, C., Cantenaut, A., Cid, C., 274 Gilbert, H., Johansson, T., Parker, M., Preneel, B., 275 Rijmen, V., and M. Robshaw, "The eSTREAM Portfolio (rev. 276 1)", September 2008, 277 . 279 [CBC-ATTACK] 280 AlFardan, N. and K. Paterson, "Lucky Thirteen: Breaking 281 the TLS and DTLS Record Protocols", IEEE Symposium on 282 Security and Privacy , 2013. 284 [RC4-ATTACK] 285 Isobe, T., Ohigashi, T., Watanabe, Y., and M. Morii, "Full 286 Plaintext Recovery Attack on Broadcast RC4", International 287 Workshop on Fast Software Encryption , 2013. 289 [SALSA20-ATTACK] 290 Aumasson, J-P., Fischer, S., Khazaei, S., Meier, W., and 291 C. Rechberger, "New Features of Latin Dances: Analysis of 292 Salsa, ChaCha, and Rumba", 2007, 293 . 295 [NIST-SHA3] 296 Chang, S., Burr, W., Kelsey, J., Paul, S., and L. Bassham, 297 "Third-Round Report of the SHA-3 Cryptographic Hash 298 Algorithm Competition", 2012, 299 . 301 Authors' Addresses 303 Adam Langley 304 Google Inc 306 Email: agl@google.com 308 Wan-Teh Chang 309 Google Inc 311 Email: wtc@google.com 313 Nikos Mavrogiannopoulos 314 Red Hat 316 Email: nmav@redhat.com 318 Joachim Strombergson 319 Secworks Sweden AB 321 Email: joachim@secworks.se 322 URI: http://secworks.se/ 323 Simon Josefsson 324 SJD AB 326 Email: simon@josefsson.org 327 URI: http://josefsson.org/