RFC 7905

ChaCha20-Poly1305 Cipher Suites for Transport Layer Security (TLS)

📅 published June 2016, from ietf

RFC 7905: ChaCha20-Poly1305 Cipher Suites for Transport Layer Security (TLS) 🦋 (Part 1 of 2)

okay bestie, this is RFC 7905, and it's giving ChaCha20-Poly1305 realness ✨. It came out in June 2016 as a Standards Track document, so it's an actual Internet standard and not just a suggestion 💅. Five people wrote it: A. Langley and W. Chang from Google, N. Mavrogiannopoulos from Red Hat, J. Strombergson from Secworks Sweden AB, and S. Josefsson from SJD AB 🫶. It's identified as RFC 7905 and ISSN 2070-1721. The big news is that it updates RFC 5246 and RFC 6347, which are TLS 1.2 and DTLS 1.2. So it's basically adding new cipher suites to the existing protocols, which is so iconic 🔥.

Abstract

okay so the whole point of this doc is to explain how the ChaCha stream cipher and the Poly1305 authenticator get used in TLS and DTLS 🌸. That's it, that's the tea. And yes, it updates RFCs 5246 and 6347 🍓.

Status of This Memo

this bit is the official paperwork 📜. It's an Internet Standards Track document, and it's a product of the IETF, which represents the consensus of the IETF community 🤝. It got public review and was approved for publication by the Internet Engineering Steering Group (IESG) 💜. If you want more on Internet Standards, check Section 2 of RFC 7841 ✨. The current status, any errata, and how to give feedback live at http://www.rfc-editor.org/info/rfc7905 🌈.

more paperwork but make it cute 🎀. 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) as they were in effect on the date of publication. Please actually read these, because they're about your rights and restrictions for this doc 🙈. Code Components pulled out of this document must include the Simplified BSD License text, as described in Section 4.e of the Trust Legal Provisions, and they come with no warranty, as the Simplified BSD License describes 💅.

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

1. Introduction ✨

okay so this doc describes how ChaCha20 and Poly1305 get used in version 1.2 or later of TLS [RFC5246], and also in version 1.2 or later of DTLS [RFC6347] 🦋.

now the cipher itself. ChaCha [CHACHA] is a stream cipher that D. J. Bernstein made in 2008 🧚. It's a refinement of Salsa20, which is one of the ciphers picked for the eSTREAM portfolio [ESTREAM], and it was the core of the SHA-3 finalist BLAKE 👑. Iconic lineage, honestly.

the version of ChaCha in this doc has 20 rounds, a 96-bit nonce, and a 256-bit key. It's called "ChaCha20" 💖. It's the conservative option when it comes to security in the ChaCha family, and it's described in [RFC7539] 🫶.

Poly1305 [POLY1305] is a Wegman-Carter, one-time authenticator that D. J. Bernstein designed 🌈. It takes a 256-bit one-time key and a message, and it spits out a 16-byte tag. The tag authenticates the message so that an attacker has a negligible chance of making a valid tag for a fake message 🔒. It's also described in [RFC7539] 💅.

ChaCha and Poly1305 were both built for high performance in software ⚡. They usually have compact implementations that use few resources and cheap operations, so they fit a wide range of architectures 🌸. They were also designed to minimize information leaking through side channels 🙈.

now the drama. Recent attacks [CBC-ATTACK] showed problems with the CBC-mode cipher suites in TLS and DTLS 💀. There were also issues with RC4, which was the only supported stream cipher [RC4-ATTACK] 😭. The existing AEAD cipher suites based on AES-GCM fix some of these issues, but people are worried about their performance and how easy they are to implement in software 🍓.

so the plan is a new stream cipher to replace RC4 and fix all the earlier problems 🎀. This doc describes a secure stream cipher for both TLS and DTLS. It's comparable to RC4 in speed on a wide range of platforms, and it can be implemented easily without being vulnerable to software side-channel attacks 🦋. Main character energy 👑.

2. ChaCha20 Cipher Suites 💅

the ChaCha20 and Poly1305 primitives get built into an AEAD algorithm [RFC5116] called AEAD_CHACHA20_POLY1305, as described in [RFC7539] 💖. This AEAD gets put into TLS and DTLS the way Section 6.2.3.3 of [RFC5246] says 🫶.

AEAD_CHACHA20_POLY1305 needs a 96-bit nonce, and it gets built like this 🌈:

  1. Take the 64-bit record sequence number, serialize it as an 8-byte, big-endian value, and pad it on the left with four 0x00 bytes 🧚.
  2. XOR the padded sequence number with the client_write_IV when the client is sending, or with the 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 🌸.

okay so this nonce construction is different from the one AES-GCM uses in TLS 1.2, but it matches the scheme that's expected for TLS 1.3 👑. The nonce comes from the record sequence number and the shared secret, and the recipient knows both 🔑. The best part is that no explicit per-record nonce has to be sent 💜. That saves eight bytes per record, and it stops implementations from accidentally using a random nonce 🙈. In the terms of [RFC5246], SecurityParameters.fixed_iv_length is twelve bytes and SecurityParameters.record_iv_length is zero bytes 🦋.

the nonce thing is the big gotcha here, bestie. The nonce is built from the sequence number and the shared secret, so there's no random nonce to mess up 💀.

these 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 suites are unchanged 🌷. So they work the way [RFC5246], [RFC4492], and [RFC5489] already define them 🫶.

the pseudorandom function (PRF) for every cipher suite in this doc is the TLS PRF with SHA-256 [FIPS180-4] as its hash function 💖.

(continued in part 2, stay tuned 🫶💅)

5.2. Informative References ✨

okay so these are the informative ones, aka the "good to know" sources. they're not required reading, but they're where the receipts are 💅

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/ 👑

the whole crew, iconic. the end of RFC 7905, periodt 💜✨

📦 where this page comes from