idnits 2.17.1 draft-mavrogiannopoulos-chacha-tls-02.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 (March 3, 2014) is 3707 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 138 -- Looks like a reference, but probably isn't: '8' on line 139 ** Obsolete normative reference: RFC 2246 (Obsoleted by RFC 4346) ** Obsolete normative reference: RFC 4346 (Obsoleted by RFC 5246) ** Obsolete normative reference: RFC 4347 (Obsoleted by RFC 6347) ** 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 ** Downref: Normative reference to an Informational RFC: RFC 6234 ** Obsolete normative reference: RFC 6347 (Obsoleted by RFC 9147) == Outdated reference: A later version (-06) exists of draft-nir-cfrg-chacha20-poly1305-01 ** Downref: Normative reference to an Informational draft: draft-nir-cfrg-chacha20-poly1305 (ref. 'I-D.nir-cfrg-chacha20-poly1305') Summary: 9 errors (**), 0 flaws (~~), 2 warnings (==), 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 Google Inc 5 (if approved) N. Mavrogiannopoulos 6 Intended status: Standards Track Red Hat 7 Expires: September 4, 2014 J. Strombergson 8 Secworks Sweden AB 9 S. Josefsson 10 SJD AB 11 March 3, 2014 13 The ChaCha Stream Cipher for Transport Layer Security 14 draft-mavrogiannopoulos-chacha-tls-02 16 Abstract 18 This document describes the use of the ChaCha stream cipher with 19 HMAC-SHA1 and Poly1305 in Transport Layer Security (TLS) and Datagram 20 Transport 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 September 4, 2014. 39 Copyright Notice 41 Copyright (c) 2014 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 . . . . . . . . . . . . . . . . . . . . . . . . . 3 57 2. The ChaCha Cipher . . . . . . . . . . . . . . . . . . . . . . 4 58 3. The Poly1305 Authenticator . . . . . . . . . . . . . . . . . . 5 59 4. ChaCha20 Cipher Suites . . . . . . . . . . . . . . . . . . . . 6 60 4.1. ChaCha20 Cipher Suites with HMAC-SHA1 . . . . . . . . . . 6 61 4.2. ChaCha20 Cipher Suites with Poly1305 . . . . . . . . . . . 7 62 5. Updates to the TLS Standard Stream Cipher . . . . . . . . . . 8 63 6. Updates to DTLS . . . . . . . . . . . . . . . . . . . . . . . 9 64 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10 65 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 66 9. Security Considerations . . . . . . . . . . . . . . . . . . . 12 67 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 68 10.1. Normative References . . . . . . . . . . . . . . . . . . . 13 69 10.2. Informative References . . . . . . . . . . . . . . . . . . 13 70 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15 72 1. Introduction 74 This document describes the use of the ChaCha stream cipher in the 75 Transport Layer Security (TLS) version 1.0 [RFC2246], TLS version 1.1 76 [RFC4346], and TLS version 1.2 [RFC5246] protocols, as well as in the 77 Datagram Transport Layer Security (DTLS) versions 1.0 [RFC4347] and 78 1.2 [RFC6347]. It can also be used with Secure Sockets Layer (SSL) 79 version 3.0 [RFC6101]. 81 ChaCha [CHACHA] is a stream cipher that has been designed for high 82 performance in software implementations. The cipher has compact 83 implementation and uses few resources and inexpensive operations that 84 makes it suitable for implementation on a wide range of 85 architectures. It has been designed to prevent leakage of 86 information through side channel analysis, has a simple and fast key 87 setup and provides good overall performance. It is a variant of 88 Salsa20 [SALSA20SPEC] which is one of the selected ciphers in the 89 eSTREAM portfolio [ESTREAM]. 91 Recent attacks [CBC-ATTACK] have indicated problems with CBC-mode 92 cipher suites in TLS and DTLS as well as issues with the only 93 supported stream cipher (RC4) [RC4-ATTACK]. While the existing AEAD 94 (AES-GCM) ciphersuites address some of these issues, concerns about 95 the performance and ease of software implementation are sometimes 96 raised. 98 Therefore, a new stream cipher to replace RC4 and address all the 99 previous issues is needed. It is the purpose of this document to 100 describe a secure stream cipher for both TLS and DTLS that is 101 comparable to RC4 in speed on a wide range of platforms and can be 102 implemented easily without being vulnerable to software side-channel 103 attacks. 105 2. The ChaCha Cipher 107 ChaCha [CHACHA] is a stream cipher developed by D. J. Bernstein in 108 2008. It is a refinement of Salsa20 and was used as the core of the 109 SHA-3 finalist, BLAKE. 111 The variant of ChaCha used in this document is ChaCha with 20 rounds, 112 a 96-bit nonce and a 256 bit key, which will be referred to as 113 ChaCha20 in the rest of this document. This is the conservative 114 variant (with respect to security) of the ChaCha family and is 115 described in [I-D.nir-cfrg-chacha20-poly1305]. 117 3. The Poly1305 Authenticator 119 Poly1305 [POLY1305] is a Wegman-Carter, one-time authenticator 120 designed by D. J. Bernstein. Poly1305 takes a 32-byte, one-time key 121 and a message and produces a 16-byte tag that authenticates the 122 message such that an attacker has a negligible chance of producing a 123 valid tag for an inauthentic message. It is described in 124 [I-D.nir-cfrg-chacha20-poly1305]. 126 4. ChaCha20 Cipher Suites 128 In the next sections different ciphersuites are defined that utilize 129 the ChaCha20 cipher combined with various message authentication 130 methods. 132 In all cases, the ChaCha20 cipher, as in 133 [I-D.nir-cfrg-chacha20-poly1305], uses a 96-bit nonce. That nonce is 134 updated on the encryption of every TLS record, and is formed as 135 follows. 137 struct { 138 opaque salt[4]; 139 opaque record_counter[8]; 140 } ChaChaNonce; 142 The salt is generated as part of the handshake process. It is either 143 the client_write_IV (when the client is sending) or the 144 server_write_IV (when the server is sending). The salt length 145 (SecurityParameters.fixed_iv_length) is 4 bytes. The record_counter 146 is the 64-bit TLS record sequence number. In case of DTLS the 147 record_counter is formed as the concatenation of the 16-bit epoch 148 with the 48-bit sequence number. 150 In both TLS and DTLS the ChaChaNonce is implicit and not sent as part 151 of the packet. 153 The pseudorandom function (PRF) for TLS 1.2 is the TLS PRF with SHA- 154 256 as the hash function. When used with TLS versions prior to 1.2, 155 the PRF is calculated as specified in the appropriate version of the 156 TLS specification. 158 The RSA, DHE_RSA, ECDHE_RSA, ECDHE_ECDSA, PSK, DHE_PSK, RSA_PSK, 159 ECDHE_PSK key exchanges are performed as defined in [RFC5246], 160 [RFC4492], and [RFC5489]. 162 4.1. ChaCha20 Cipher Suites with HMAC-SHA1 164 The following CipherSuites are defined. 166 TLS_RSA_WITH_CHACHA20_SHA = {0xTBD, 0xTBD} 167 TLS_ECDHE_RSA_WITH_CHACHA20_SHA = {0xTBD, 0xTBD} 168 TLS_ECDHE_ECDSA_WITH_CHACHA20_SHA = {0xTBD, 0xTBD} 170 TLS_DHE_RSA_WITH_CHACHA20_SHA = {0xTBD, 0xTBD} 171 TLS_DHE_PSK_WITH_CHACHA20_SHA = {0xTBD, 0xTBD} 173 TLS_PSK_WITH_CHACHA20_SHA = {0xTBD, 0xTBD} 174 TLS_ECDHE_PSK_WITH_CHACHA20_SHA = {0xTBD, 0xTBD} 175 TLS_RSA_PSK_WITH_CHACHA20_SHA = {0xTBD, 0xTBD} 177 The MAC algorithm used in the ciphersuites above is HMAC-SHA1 178 [RFC6234]. 180 4.2. ChaCha20 Cipher Suites with Poly1305 182 The ChaCha20 and Poly1305 primitives are built into an AEAD algorithm 183 [RFC5116], AEAD_CHACHA20_POLY1305, described in 184 [I-D.nir-cfrg-chacha20-poly1305]. It takes as input a 256-bit key 185 and a 96-bit nonce. 187 When used in TLS, the "record_iv_length" is zero and the nonce is set 188 to be the ChaChaNonce. The additional data is seq_num + 189 TLSCompressed.type + TLSCompressed.version + TLSCompressed.length, 190 where "+" denotes concatenation. 192 The following CipherSuites are defined. 194 TLS_RSA_WITH_CHACHA20_POLY1305 = {0xTBD, 0xTBD} 195 TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305 = {0xTBD, 0xTBD} 196 TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305 = {0xTBD, 0xTBD} 198 TLS_DHE_RSA_WITH_CHACHA20_POLY1305 = {0xTBD, 0xTBD} 199 TLS_DHE_PSK_WITH_CHACHA20_POLY1305 = {0xTBD, 0xTBD} 201 TLS_PSK_WITH_CHACHA20_POLY1305 = {0xTBD, 0xTBD} 202 TLS_ECDHE_PSK_WITH_CHACHA20_POLY1305 = {0xTBD, 0xTBD} 203 TLS_RSA_PSK_WITH_CHACHA20_POLY1305 = {0xTBD, 0xTBD} 205 5. Updates to the TLS Standard Stream Cipher 207 The ChaCha20 ciphersuites with HMAC-SHA1 defined in this document 208 differ from the TLS RC4 ciphersuites that have been the basis for the 209 definition of Standard Stream Cipher. Unlike RC4, ChaCha20 requires 210 a nonce per record. This however, does not affect the description of 211 the Standard Stream Cipher if one assumes that a nonce is optional 212 and depends on the cipher's characteristics. 214 Hence, this document modifies the Standard Stream Cipher by adding an 215 implicit nonce. The implicit nonce may consist of 217 o an optional fixed component ("salt"), generated from the 218 key_block; 220 o a variable component, based on the 64-bit TLS record sequence 221 number or the concatenation of the 16-bit epoch with the 48-bit 222 sequence number in case of DTLS. 224 Stream ciphers that don't require a nonce such as RC4 shall ignore 225 it. Other stream ciphers that require a nonce, such as ChaCha20 with 226 HMAC-SHA1, will use the nonce and reset their state on each record. 228 6. Updates to DTLS 230 The DTLS protocol requires the cipher in use to introduce no 231 dependencies between TLS Records to allow lost or rearranged records. 232 For that it explicitly bans stream ciphers (see Section 3.1 of 233 [RFC6347]). 235 As the stream cipher described in this document, unlike RC4, does not 236 require dependencies between records, this ban of stream ciphers is 237 lifted with this document. Stream ciphers can be used with DTLS if 238 they introduce no dependencies between records. 240 7. Acknowledgements 242 The authors would like to thank Zooko Wilcox-OHearn and Samuel Neves. 244 8. IANA Considerations 246 IANA is requested to assign the following Cipher Suites in the TLS 247 Cipher Suite Registry: 249 TLS_RSA_WITH_CHACHA20_POLY1305 = {0xTBD, 0xTBD} 250 TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305 = {0xTBD, 0xTBD} 251 TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305 = {0xTBD, 0xTBD} 253 TLS_DHE_RSA_WITH_CHACHA20_POLY1305 = {0xTBD, 0xTBD} 254 TLS_DHE_PSK_WITH_CHACHA20_POLY1305 = {0xTBD, 0xTBD} 256 TLS_PSK_WITH_CHACHA20_POLY1305 = {0xTBD, 0xTBD} 257 TLS_ECDHE_PSK_WITH_CHACHA20_POLY1305 = {0xTBD, 0xTBD} 258 TLS_RSA_PSK_WITH_CHACHA20_POLY1305 = {0xTBD, 0xTBD} 260 TLS_RSA_WITH_CHACHA20_SHA = {0xTBD, 0xTBD} 261 TLS_ECDHE_RSA_WITH_CHACHA20_SHA = {0xTBD, 0xTBD} 262 TLS_ECDHE_ECDSA_WITH_CHACHA20_SHA = {0xTBD, 0xTBD} 264 TLS_DHE_RSA_WITH_CHACHA20_SHA = {0xTBD, 0xTBD} 265 TLS_DHE_PSK_WITH_CHACHA20_SHA = {0xTBD, 0xTBD} 267 TLS_PSK_WITH_CHACHA20_SHA = {0xTBD, 0xTBD} 268 TLS_ECDHE_PSK_WITH_CHACHA20_SHA = {0xTBD, 0xTBD} 269 TLS_RSA_PSK_WITH_CHACHA20_SHA = {0xTBD, 0xTBD} 271 9. Security Considerations 273 ChaCha20 follows the same basic principle as Salsa20, a cipher with 274 significant security review [SALSA20-SECURITY][ESTREAM]. At the time 275 of writing this document, there are no known significant security 276 problems with either cipher, and ChaCha20 is shown to be more 277 resistant in certain attacks than Salsa20 [SALSA20-ATTACK]. 278 Furthermore ChaCha20 was used as the core of the BLAKE hash function, 279 a SHA3 finalist, that had received considerable cryptanalytic 280 attention [NIST-SHA3]. 282 Poly1305 is designed to ensure that forged messages are rejected with 283 a probability of 1-(n/2^102) for a 16*n byte message, even after 284 sending 2^64 legitimate messages. 286 The cipher suites described in this document require that an nonce is 287 never repeated under the same key. The design presented ensures that 288 by using the TLS sequence number which is unique and does not wrap 289 [RFC5246]. 291 This document should not introduce any other security considerations 292 than those that directly follow from the use of the stream cipher 293 ChaCha20, the AEAD_CHACHA20_POLY1305 construction, and those that 294 directly follow from introducing any set of stream cipher suites into 295 TLS and DTLS (see also the Security Considerations section of 296 [I-D.nir-cfrg-chacha20-poly1305]). 298 10. References 300 10.1. Normative References 302 [RFC2246] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", 303 RFC 2246, January 1999. 305 [RFC4346] Dierks, T. and E. Rescorla, "The Transport Layer Security 306 (TLS) Protocol Version 1.1", RFC 4346, April 2006. 308 [RFC4347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 309 Security", RFC 4347, April 2006. 311 [RFC4492] Blake-Wilson, S., Bolyard, N., Gupta, V., Hawk, C., and B. 312 Moeller, "Elliptic Curve Cryptography (ECC) Cipher Suites 313 for Transport Layer Security (TLS)", RFC 4492, May 2006. 315 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 316 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 318 [RFC5489] Badra, M. and I. Hajjeh, "ECDHE_PSK Cipher Suites for 319 Transport Layer Security (TLS)", RFC 5489, March 2009. 321 [RFC6234] Eastlake, D. and T. Hansen, "US Secure Hash Algorithms 322 (SHA and SHA-based HMAC and HKDF)", RFC 6234, May 2011. 324 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 325 Security Version 1.2", RFC 6347, January 2012. 327 [I-D.nir-cfrg-chacha20-poly1305] 328 Nir, Y. and A. Langley, "ChaCha20 and Poly1305 for IETF 329 protocols", draft-nir-cfrg-chacha20-poly1305-01 (work in 330 progress), January 2014. 332 10.2. Informative References 334 [CHACHA] Bernstein, D., "ChaCha, a variant of Salsa20", 335 January 2008, 336 . 338 [POLY1305] 339 Bernstein, D., "The Poly1305-AES message-authentication 340 code.", March 2005, 341 . 343 [RFC5116] McGrew, D., "An Interface and Algorithms for Authenticated 344 Encryption", RFC 5116, January 2008. 346 [SALSA20SPEC] 347 Bernstein, D., "Salsa20 specification", April 2005, 348 . 350 [RFC6101] Freier, A., Karlton, P., and P. Kocher, "The Secure 351 Sockets Layer (SSL) Protocol Version 3.0", RFC 6101, 352 August 2011. 354 [SALSA20-SECURITY] 355 Bernstein, D., "Salsa20 security", April 2005, 356 . 358 [ESTREAM] Babbage, S., DeCanniere, C., Cantenaut, A., Cid, C., 359 Gilbert, H., Johansson, T., Parker, M., Preneel, B., 360 Rijmen, V., and M. Robshaw, "The eSTREAM Portfolio (rev. 361 1)", September 2008, 362 . 364 [CBC-ATTACK] 365 AlFardan, N. and K. Paterson, "Lucky Thirteen: Breaking 366 the TLS and DTLS Record Protocols", IEEE Symposium on 367 Security and Privacy , 2013. 369 [RC4-ATTACK] 370 Isobe, T., Ohigashi, T., Watanabe, Y., and M. Morii, "Full 371 Plaintext Recovery Attack on Broadcast RC4", International 372 Workshop on Fast Software Encryption , 2013. 374 [SALSA20-ATTACK] 375 Aumasson, J-P., Fischer, S., Khazaei, S., Meier, W., and 376 C. Rechberger, "New Features of Latin Dances: Analysis of 377 Salsa, ChaCha, and Rumba", 2007, 378 . 380 [NIST-SHA3] 381 Chang, S., Burr, W., Kelsey, J., Paul, S., and L. Bassham, 382 "Third-Round Report of the SHA-3 Cryptographic Hash 383 Algorithm Competition", 2012, 384 . 386 Authors' Addresses 388 Adam Langley 389 Google Inc 391 Email: agl@google.com 393 Wan-Teh Chang 394 Google Inc 396 Email: wtc@google.com 398 Nikos Mavrogiannopoulos 399 Red Hat 401 Email: nmav@redhat.com 403 Joachim Strombergson 404 Secworks Sweden AB 406 Email: joachim@secworks.se 407 URI: http://secworks.se/ 409 Simon Josefsson 410 SJD AB 412 Email: simon@josefsson.org 413 URI: http://josefsson.org/