Network Working Group | N. Mavrogiannopoulos |
Internet-Draft | Red Hat |
Intended status: Informational | J. Strombergson |
Expires: June 12, 2014 | Secworks Sweden AB |
S. Josefsson | |
SJD AB | |
December 09, 2013 |
The ChaCha Stream Cipher for Transport Layer Security
draft-mavrogiannopoulos-chacha-tls-00
This document describe how the Chacha stream cipher can be used in the Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS) protocols.
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."
This Internet-Draft will expire on June 12, 2014.
Copyright (c) 2013 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.
This document describe how the Chacha stream cipher can be used in the Transport Layer Security (TLS) version 1.0 [RFC2246], TLS version 1.1 [RFC4346], and TLS version 1.2 [RFC5246] protocols, as well as in the Datagram Transport Layer Security (DTLS) versions 1.0 [RFC4347] and 1.2 [RFC6347]. It can also be used with Secure Sockets Layer (SSL) version 3.0 [RFC6101].
Chacha [CHACHASPEC] is a stream cipher that has been designed for high performance in software implementations. The cipher has compact implementation and uses few resources and inexpensive operations that makes it suitable for implementation on a wide range of architectures. It has been designed to prevent leakage of information through side channel analysis, has a simple and fast key setup and provides good overall performance. It is a variant of Salsa20 [SALSA20SPEC] which is one of the selected ciphers in the eSTREAM portfolio [ESTREAM].
Recent attacks [CBC-ATTACK] have indicated problems with CBC-mode cipher suites in TLS and DTLS as well as issues with the only supported stream cipher (RC4) [RC4-ATTACK]. While the existing AEAD ciphersuites address these issues, concerns about their performance, on general purpose CPUs, are sometimes raised [AEAD-PERFORMANCE]. Moreover, the DTLS protocol cannot take advantage of the fast RC4 stream cipher because it does not provide random access in the key stream.
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.
The variant of Chacha used in this draft is Chacha with 20 rounds and a 256 bit key. This is the conservative with respect to security variant of the Chacha family. Test vectors for this cipher can be found at [I-D.strombergson-chacha-test-vectors].
In the next sections different ciphersuites are defined that utilize the Chacha cipher combined with various MAC methods.
In all cases, the pseudorandom function (PRF) for TLS 1.2 is the TLS PRF with SHA-256 as the hash function. When used with TLS versions prior to 1.2, the PRF is calculated as specified in the appropriate version of the TLS specification.
The following CipherSuites are defined: (note that the third column contains the suggested to IANA ciphersuite numbers)
TLS_RSA_WITH_CHACHA_SHA1 = {0xTBD, 0xTBD} {0xE5, 0x00} TLS_ECDHE_RSA_WITH_CHACHA_SHA1 = {0xTBD, 0xTBD} {0xE5, 0x01} TLS_ECDHE_ECDSA_WITH_CHACHA_SHA1 = {0xTBD, 0xTBD} {0xE5, 0x02} TLS_PSK_WITH_CHACHA_SHA1 = {0xTBD, 0xTBD} {0xE5, 0x03} TLS_ECDHE_PSK_WITH_CHACHA_SHA1 = {0xTBD, 0xTBD} {0xE5, 0x04} TLS_RSA_PSK_WITH_CHACHA_SHA1 = {0xTBD, 0xTBD} {0xE5, 0x05} TLS_DHE_PSK_WITH_CHACHA_SHA1 = {0xTBD, 0xTBD} {0xE5, 0x06} TLS_DHE_RSA_WITH_CHACHA_SHA1 = {0xTBD, 0xTBD} {0xE5, 0x07}
Note that Chacha requires a 64-bit nonce. That nonce is updated on the encryption of every TLS record, and is set to be the 64-bit TLS record sequence number. In case of DTLS the 64-bit nonce is formed as the concatenation of the 16-bit epoch with the 48-bit sequence number.
The RSA, DHE_RSA, ECDHE_RSA, ECDHE_ECDSA, PSK, DHE_PSK, RSA_PSK, ECDHE_PSK key exchanges are performed as defined in [RFC5246], [RFC4492], and [RFC5489].
The MAC algorithm used in the ciphersuites above is HMAC-SHA1 [RFC6234].
The ciphersuites defined in this document differ from the TLS RC4 ciphersuites that have been the basis for the definition of GenericStreamCipher. Unlike RC4, Chacha requires a nonce per record. This however, does not affect the description of the GenericStreamCipher if one assumes that a nonce is optional and depends on the cipher's characteristics (in that case RC4 uses a 0 byte nonce, and Chacha an 8-byte nonce).
As specified in TLS [RFC5246] the MAC is computed before encryption and the stream cipher encrypts the entire block, including the MAC.
The authors would like to thank Zooko Wilcox-OHearn and Samuel Neves for suggestions that led to this draft.
IANA is requested to allocate the following numbers in the TLS Cipher Suite Registry (note that the third column contains the suggested ciphersuite numbers):
TLS_RSA_WITH_CHACHA_SHA1 = {0xTBD, 0xTBD} {0xE5, 0x00} TLS_ECDHE_RSA_WITH_CHACHA_SHA1 = {0xTBD, 0xTBD} {0xE5, 0x01} TLS_ECDHE_ECDSA_WITH_CHACHA_SHA1 = {0xTBD, 0xTBD} {0xE5, 0x02} TLS_PSK_WITH_CHACHA_SHA1 = {0xTBD, 0xTBD} {0xE5, 0x03} TLS_ECDHE_PSK_WITH_CHACHA_SHA1 = {0xTBD, 0xTBD} {0xE5, 0x04} TLS_RSA_PSK_WITH_CHACHA_SHA1 = {0xTBD, 0xTBD} {0xE5, 0x05} TLS_DHE_PSK_WITH_CHACHA_SHA1 = {0xTBD, 0xTBD} {0xE5, 0x06} TLS_DHE_RSA_WITH_CHACHA_SHA1 = {0xTBD, 0xTBD} {0xE5, 0x07}
Chacha follows the same basic principle as Salsa20, 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 Chacha is shown to be more resistant in certain attacks than Salsa20 [SALSA20-ATTACK]. Furthermore Chacha was used as the core of the BLAKE hash function, a SHA3 finalist, that had received considerable cryptanalytic attention [NIST-SHA3].
This document should not introduce any other security considerations than those that directly follow from any use of the stream cipher Chacha and those that directly follow from introducing any set of stream cipher suites into TLS and DTLS.