idnits 2.17.1 draft-housley-cms-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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (4 April 2016) is 2936 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) ** Obsolete normative reference: RFC 7539 (ref. 'FORIETF') (Obsoleted by RFC 8439) -- Possible downref: Non-RFC (?) normative reference: ref. 'X680' -- Possible downref: Non-RFC (?) normative reference: ref. 'X690' Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet-Draft R. Housley 3 Intended status: Standards Track Vigil Security 4 Expires: 4 October 2016 4 April 2016 6 Using ChaCha20-Poly1305 Authenticated Encryption 7 in the Cryptographic Message Syntax (CMS) 9 draft-housley-cms-chacha20-poly1305-00 11 Abstract 13 This document describes the conventions for using ChaCha20-Poly1305 14 Authenticated Encryption in the Cryptographic Message Syntax (CMS). 15 ChaCha20-Poly1305 is a construction of the ChaCha stream cipher and 16 Poly1305 authenticator. 18 Status of This Memo 20 This Internet-Draft is submitted in full conformance with the 21 provisions of BCP 78 and BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF). Note that other groups may also distribute 25 working documents as Internet-Drafts. The list of current Internet- 26 Drafts is at http://datatracker.ietf.org/drafts/current/. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 This Internet-Draft will expire on 4 October 2016. 35 Copyright Notice 37 Copyright (c) 2016 IETF Trust and the persons identified as the 38 document authors. All rights reserved. 40 This document is subject to BCP 78 and the IETF Trust's Legal 41 Provisions Relating to IETF Documents 42 (http://trustee.ietf.org/license-info) in effect on the date of 43 publication of this document. Please review these documents 44 carefully, as they describe your rights and restrictions with respect 45 to this document. Code Components extracted from this document must 46 include Simplified BSD License text as described in Section 4.e of 47 the Trust Legal Provisions and are provided without warranty as 48 described in the Simplified BSD License. 50 1. Introduction 52 This document specifies the conventions for using the 53 ChaCha20-Poly1305 Authenticated Encryption as the content- 54 authenticated-encryption algorithm with the Cryptographic Message 55 Syntax (CMS) [CMS] authenticated-enveloped-data content type 56 [AUTHENV]. 58 ChaCha [CHACHA] is a stream cipher developed by D. J. Bernstein in 59 2008. It is a refinement of Salsa20, which is one of the ciphers in 60 the eSTREAM portfolio [ESTREAM]. 62 ChaCha20 is the 20-round variant of ChaCha; it requires a 256-bit key 63 and a 96-bit nonce. ChaCha20 is described in [FORIETF]. 65 Poly1305 [POLY1305] is a Wegman-Carter, one-time authenticator 66 designed by D. J. Bernstein. Poly1305 produces a 16-byte 67 authentication tag; it requires a a 256-bit, single-use key. 68 Poly1305 is also described in [FORIETF]. 70 ChaCha20 and Poly1305 have been designed for high performance in 71 software implementations. They can typically be implemented with few 72 resources and inexpensive operations, making them suitable on a wide 73 range of systems. They have also been designed to minimize leakage 74 of information through side channels. 76 1.1. The ChaCha20 and Poly1305 AEAD Construction 78 ChaCha20 and Poly1305 have been combined to create an Authenticated 79 Encryption with Associated Data (AEAD) algorithm [AEAD]. This AEAD 80 algorithm is often referred to as AEAD_CHACHA20_POLY1305, and it is 81 described in [FORIETF]. 83 AEAD_CHACHA20_POLY1305 accepts four inputs: a 256-bit key, a 96-bit 84 nonce, an arbitrary length plaintext, and an arbitrary length 85 additional authenticated data (AAD). A nonce value cannot be used 86 securely more than once with the same key. 88 A high-level summary of AEAD_CHACHA20_POLY1305 authenticated 89 encryption processing is: 91 1) A Poly1305 one-time key is generated from the 256-bit key and 92 and nonce using the procedure described in Section 2.6 of 93 [FORIETF]. 95 2) The ChaCha20 encryption function is used to encrypt the 96 plaintext, using the same key and nonce, and with the initial 97 counter set to 1. 99 3) The Poly1305 function is used with the Poly1305 key from 100 step 1, and a buffer constructed as a concatenation of the AAD, 101 padding1, the ciphertext, padding2, the length of the AAD in 102 octets, and the length of the ciphertext in octets. The 103 padding fields contain up to 15 octets, with all bits set to 104 zero, and the padding brings the total length of the buffer so 105 far to an integral multiple of 16. If the buffer length was 106 already an integral multiple of 16 octets, then the padding 107 field is zero octets. The length fields contain 64-bit little- 108 endian integers. 110 AEAD_CHACHA20_POLY1305 produces ciphertext of the same length as the 111 plaintext and a 128-bit authentication tag. 113 AEAD_CHACHA20_POLY1305 authenticated decryption processing is similar 114 to the encryption processing. Of course, the roles of ciphertext and 115 plaintext are reversed, so the ChaCha20 encryption function is 116 applied to the ciphertext, producing the plaintext. The Poly1305 117 function is run over the AAD and the ciphertext, not the plaintext, 118 and the resulting authentication tag is bitwise compared to the 119 received authentication tag. The message is authenticated if and 120 only if the calculated and received authentication tags match. 122 1.2. Terminology 124 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 125 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 126 document are to be interpreted as described in RFC 2119 [STDWORDS]. 128 1.3. ASN.1 130 CMS values are generated using ASN.1 [X680], which uses the Basic 131 Encoding Rules (BER) and the Distinguished Encoding Rules (DER) 132 [X690]. 134 2. Automated Key Management 136 The reuse of an ChaCha20 and Poly1305 AEAD nonce/key combination 137 destroys the security guarantees. As a result, it can be extremely 138 difficult to use the ChaCha20 and Poly1305 AEAD securely when using 139 statically configured keys. For safety's sake, implementations MUST 140 use an automated key management system [KEYMGMT]. 142 The CMS authenticated-enveloped-data content type supports four 143 general key management techniques: 145 Key Transport: the content-authenticated-encryption key is 146 encrypted in the recipient's public key; 148 Key Agreement: the recipient's public key and the sender's 149 private key are used to generate a pairwise symmetric key, then 150 the content-authenticated-encryption key is encrypted in the 151 pairwise symmetric key; 153 Symmetric Key-Encryption Keys: the content-authenticated- 154 encryption key is encrypted in a previously distributed 155 symmetric key-encryption key; and 157 Passwords: the content-authenticated-encryption key is encrypted 158 in a key-encryption key that is derived from a password or 159 other shared secret value. 161 All of these key management techniques meet the automated key 162 management system requirement as long as a fresh content- 163 authenticated-encryption key is generated for the protection of each 164 content. Note that some of these key management techniques use one 165 key-encryption key to encrypt more than one content-authenticated- 166 encryption key during the system life cycle. As long as fresh 167 content-authenticated-encryption key is used each time, 168 AEAD_CHACHA20_POLY1305 can be used safely with the CMS authenticated- 169 enveloped-data content type. 171 In addition to these four general key management techniques, CMS 172 supports other key management techniques. See Section 6.2.5 of 173 [CMS]. Since the properties of these key management techniques are 174 unknown, no statement can be made about whether these key management 175 techniques meet the automated key management system requirement. 176 Designers and implementers must perform their own analysis if one of 177 these other key management techniques is supported. 179 3. Using the AEAD_CHACHA20_POLY1305 Algorithm with AuthEnvelopedData 181 This section specifies the conventions employed by CMS 182 implementations that support content authenticated encryption using 183 the AEAD_CHACHA20_POLY1305 algorithm. 185 Content authenticated encryption algorithm identifiers are located in 186 the AuthEnvelopedData EncryptedContentInfo contentEncryptionAlgorithm 187 field. 189 Content authenticated encryption algorithms are used to encipher the 190 content located in the AuthEnvelopedData EncryptedContentInfo 191 encryptedContent field and to provide the message authentication code 192 for the AuthEnvelopedData mac field. Note that the message 193 authentication code provides integrity protection for both the 194 AuthEnvelopedData authAttrs and the AuthEnvelopedData 195 EncryptedContentInfo encryptedContent. 197 Neither the plaintext content nor the optional AAD inputs need to be 198 padded prior to invoking the AEAD_CHACHA20_POLY1305 Algorithm. 200 There is one algorithm identifiers for the AEAD_CHACHA20_POLY1305 201 algorithm: 203 id-alg-AEADChaCha20Poly1305 OBJECT IDENTIFIER ::= 204 { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) 205 pkcs9(9) smime(16) alg(3) TBD1 } 207 The AlgorithmIdentifier parameters field MUST be present, and the 208 parameters field must contain a AEADChaCha20Poly1305Nonce: 210 AEADChaCha20Poly1305Nonce ::= OCTET STRING (SIZE(12)) 212 The AEADChaCha20Poly1305Nonce contains a 12-octet nonce. With the 213 CMS, the content-authenticated-encryption key is normally used for a 214 single content. Within the scope of any content-authenticated- 215 encryption key, the nonce value MUST be unique. That is, the set of 216 nonce values used with any given key MUST NOT contain any duplicate 217 values. 219 4. IANA Considerations 221 IANA is requested to add the following entry in the SMI Security for 222 S/MIME Algorithms (1.2.840.113549.1.9.16.3) registry: 224 TBD1 id-alg-AEADChaCha20Poly1305 [This Document] 226 IANA is requested to add the following entry in the SMI Security for 227 S/MIME Module Identifier (1.2.840.113549.1.9.16.0) registry: 229 TBD2 id-mod-CMS-AEADChaCha20Poly1305 [This Document] 231 5. Security Considerations 233 The CMS AuthEnvelopedData provides all of the tools needed to avoid 234 reuse of the same nonce value under the same key. Automated key 235 management is discussed in Section 2. 237 When using AEAD_CHACHA20_POLY1305, the resulting ciphertext is always 238 the same size as the original plaintext. Some other mechanism needs 239 to be used in conjunction with AEAD_CHACHA20_POLY1305 if disclosure 240 of the size of the plaintext is a concern. 242 The amount of encrypted data possible in a single invocation of 243 AEAD_CHACHA20_POLY1305 is 2^32-1 blocks of 64 octets each, because of 244 the size of the block counter field in the ChaCha20 block function. 245 This gives a total of 247,877,906,880 octets, which likely ot be 246 sufficient to handle the size of any CMS content type. Note that 247 ciphertext length field in the authentication buffer will accomodate 248 2^64 octets, which is much larger than necessary. 250 The AEAD_CHACHA20_POLY1305 construction is a novel composition of 251 ChaCha20 and Poly1305. A security analysis of this composition is 252 given in [PROCTER]. 254 Implementations must randomly generate content-authenticated- 255 encryption keys. The use of inadequate pseudo-random number 256 generators (PRNGs) to generate cryptographic keys can result in 257 little or no security. An attacker may find it much easier to 258 reproduce the PRNG environment that produced the keys, searching the 259 resulting small set of possibilities, rather than brute force 260 searching the whole key space. The generation of quality random 261 numbers is difficult. RFC 4086 [RANDOM] offers important guidance in 262 this area. 264 6. Acknowledgements 266 Thanks to Jim Schaad for his review and insightful comments. 268 7. Normative References 270 [AUTHENV] Housley, R., "Cryptographic Message Syntax (CMS) 271 Authenticated-Enveloped-Data Content Type", RFC 5083, 272 November 2007. 274 [CMS] Housley, R., "Cryptographic Message Syntax (CMS)", RFC 275 5652, September 2009. 277 [FORIETF] Nir, Y. and A. Langley, "ChaCha20 and Poly1305 for IETF 278 Protocols", RFC 7539, May 2015. 280 [STDWORDS] Bradner, S., "Key words for use in RFCs to Indicate 281 Requirement Levels", BCP 14, RFC 2119, March 1997. 283 [X680] ITU-T, "Information technology -- Abstract Syntax Notation 284 One (ASN.1): Specification of basic notation", ITU-T 285 Recommendation X.680, 2002. 287 [X690] ITU-T, "Information technology -- ASN.1 encoding rules: 288 Specification of Basic Encoding Rules (BER), Canonical 289 Encoding Rules (CER) and Distinguished Encoding Rules 290 (DER)", ITU-T Recommendation X.690, 2002. 292 8. Informative References 294 [AEAD] McGrew, D., "An Interface and Algorithms for Authenticated 295 Encryption", RFC 5116, January 2008. 297 [CHACHA] Bernstein, D., "ChaCha, a variant of Salsa20", January 298 2008, 299 . 301 [ESTREAM] Babbage, S., DeCanniere, C., Cantenaut, A., Cid, C., 302 Gilbert, H., Johansson, T., Parker, M., Preneel, B., 303 Rijmen, V., and M. Robshaw, "The eSTREAM Portfolio 304 (rev. 1)", September 2008, 305 . 307 [KEYMGMT] Bellovin, S. and R. Housley, "Guidelines for Cryptographic 308 Key Management", BCP 107, RFC 4107, June 2005. 310 [POLY1305] Bernstein, D., "The Poly1305-AES message-authentication 311 code.", March 2005, 312 . 314 [PROCTER] Procter, G., "A Security Analysis of the Composition of 315 ChaCha20 and Poly1305", August 2014, 316 . 318 [RANDOM] Eastlake, D., Schiller, J., and S. Crocker, "Randomness 319 Recommendations for Security", BCP 106, RFC 4086, June 320 2005. 322 Appendix: ASN.1 Module 324 CMS-AEADChaCha20Poly1305 325 { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) 326 pkcs-9(9) smime(16) modules(0) TBD2 } 328 DEFINITIONS IMPLICIT TAGS ::= BEGIN 330 IMPORTS 331 CONTENT-ENCRYPTION 332 FROM AlgorithmInformation-2009 333 { iso(1) identified-organization(3) dod(6) internet(1) 334 security(5) mechanisms(5) pkix(7) id-mod(0) 335 id-mod-algorithmInformation-02(58) }; 337 -- EXPORTS All 339 AEADContentEncryptionAlgs CONTENT-ENCRYPTION ::= 340 { cea-AEADChaCha20Poly1305, ... } 342 cea-AEADChaCha20Poly1305 CONTENT-ENCRYPTION ::= { 343 IDENTIFIER id-alg-AEADChaCha20Poly1305 344 PARAMS TYPE AEADChaCha20Poly1305Nonce ARE required 345 SMIME-CAPS { IDENTIFIED BY id-alg-AEADChaCha20Poly1305 } } 347 id-alg-AEADChaCha20Poly1305 OBJECT IDENTIFIER ::= 348 { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) 349 pkcs9(9) smime(16) alg(3) TBD1 } 351 AEADChaCha20Poly1305Nonce ::= OCTET STRING (SIZE(12)) 353 END 355 Author's Addresses 357 Russell Housley 358 Vigil Security, LLC 359 918 Spring Knoll Drive 360 Herndon, VA 20170 361 USA 363 EMail: housley@vigilsec.com