idnits 2.17.1 draft-ietf-curdle-cms-chacha20-poly1305-06.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 (19 January 2017) is 2654 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) ** Obsolete normative reference: RFC 5751 (ref. 'MSG') (Obsoleted by RFC 8551) -- Possible downref: Non-RFC (?) normative reference: ref. 'X680' -- Possible downref: Non-RFC (?) normative reference: ref. 'X690' Summary: 2 errors (**), 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: 19 July 2017 19 January 2017 6 Using ChaCha20-Poly1305 Authenticated Encryption 7 in the Cryptographic Message Syntax (CMS) 9 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 an authenticated encryption algorithm 16 constructed of the ChaCha stream cipher and 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 19 July 2017. 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 ChaCha20-Poly1305 53 Authenticated Encryption with the Cryptographic Message Syntax (CMS) 54 [CMS] authenticated-enveloped-data content type [AUTHENV]. 56 ChaCha [CHACHA] is a stream cipher developed by D. J. Bernstein in 57 2008. It is a refinement of Salsa20, which is one of the ciphers in 58 the eSTREAM portfolio [ESTREAM]. 60 ChaCha20 is the 20-round variant of ChaCha; it requires a 256-bit key 61 and a 96-bit nonce. [FORIETF] provides a detailed algorithm 62 description, examples, and test vectors of ChaCha20. 64 Poly1305 [POLY1305] is a Wegman-Carter, one-time authenticator 65 designed by D. J. Bernstein. Poly1305 produces a 16-byte 66 authentication tag; it requires a 256-bit, single-use key. [FORIETF] 67 also provides a detailed algorithm description, examples, and test 68 vectors of Poly1305. 70 ChaCha20 and Poly1305 have been designed for high performance 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 [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). As the name implies, a nonce 86 value cannot be used securely more than once with the same key. 88 AEAD_CHACHA20_POLY1305 produces two outputs: ciphertext of the same 89 length as the plaintext and a 128-bit authentication tag. 91 AEAD_CHACHA20_POLY1305 authenticated decryption processing is similar 92 to the encryption processing. Of course, the roles of ciphertext and 93 plaintext are reversed, so the ChaCha20 encryption function is 94 applied to the ciphertext, producing the plaintext. The Poly1305 95 function is run over the AAD and the ciphertext, not the plaintext, 96 and the resulting authentication tag is bitwise compared to the 97 received authentication tag. The message is authenticated if and 98 only if the calculated and received authentication tags match. 100 1.2. ASN.1 102 CMS values are generated using ASN.1 [X680], which uses the Basic 103 Encoding Rules (BER) and the Distinguished Encoding Rules (DER) 104 [X690]. 106 1.3. Terminology 108 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 109 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 110 document are to be interpreted as described in RFC 2119 [STDWORDS]. 112 2. Key Management 114 The reuse of an AEAD_CHACHA20_POLY1305 nonce value with the same key 115 destroys the security guarantees. It can be extremely difficult to 116 use a statically configured AEAD_CHACHA20_POLY1305 key and never 117 repeat a nonce value; however, the CMS authenticated-enveloped-data 118 content type supports four key management techniques that allow a 119 fresh AEAD_CHACHA20_POLY1305 key to be used as the content- 120 authenticated-encryption key for a single protected content: 122 Key Transport: the fresh content-authenticated-encryption key 123 is encrypted in the recipient's public key; 125 Key Agreement: the recipient's public key and the sender's 126 private key are used to generate a pairwise symmetric key- 127 encryption key, then the fresh content-authenticated-encryption 128 key is encrypted in the pairwise symmetric key; 130 Symmetric Key-Encryption Keys: the fresh content-authenticated- 131 encryption key is encrypted in a previously distributed 132 symmetric key-encryption key; and 134 Passwords: the fresh content-authenticated-encryption key is 135 encrypted in a key-encryption key that is derived from a 136 password or other shared secret value. 138 In addition to these four general key management techniques, CMS 139 supports other key management techniques. See Section 6.2.5 of 140 [CMS]. Since the properties of these key management techniques are 141 unknown, no statement about their support of fresh content- 142 authenticated-encryption keys can be made. Designers and 143 implementers must perform their own analysis if one of these other 144 key management techniques is supported. 146 3. Using the AEAD_CHACHA20_POLY1305 Algorithm with AuthEnvelopedData 148 This section specifies the conventions employed by CMS 149 implementations that support the authenticated-enveloped-data content 150 type and the AEAD_CHACHA20_POLY1305 algorithm. 152 The AEAD_CHACHA20_POLY1305 algorithm identifier is located in the 153 AuthEnvelopedData EncryptedContentInfo contentEncryptionAlgorithm 154 field. 156 The AEAD_CHACHA20_POLY1305 algorithm is used to authenticate the 157 attributes located in the AuthEnvelopedData authAttrs field, if any 158 are present, encipher the content located in the AuthEnvelopedData 159 EncryptedContentInfo encryptedContent field, and to provide the 160 message authentication code (MAC) located in the AuthEnvelopedData 161 mac field. The authenticated attributes are DER encoded to produce 162 the AAD input value to the AEAD_CHACHA20_POLY1305 algorithm. The 163 ciphertext and the MAC are the two outputs of the 164 AEAD_CHACHA20_POLY1305 algorithm. Note that the MAC, which is called 165 the authentication tag in [FORIETF], provides integrity protection 166 for both the AuthEnvelopedData authAttrs and the AuthEnvelopedData 167 EncryptedContentInfo encryptedContent. 169 Neither the plaintext content nor the optional AAD inputs need to be 170 padded prior to invoking the AEAD_CHACHA20_POLY1305 algorithm. 172 There is one algorithm identifier for the AEAD_CHACHA20_POLY1305 173 algorithm: 175 id-alg-AEADChaCha20Poly1305 OBJECT IDENTIFIER ::= 176 { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) 177 pkcs9(9) smime(16) alg(3) TBD1 } 179 The AlgorithmIdentifier parameters field MUST be present, and the 180 parameters field MUST contain a AEADChaCha20Poly1305Nonce: 182 AEADChaCha20Poly1305Nonce ::= OCTET STRING (SIZE(12)) 184 The AEADChaCha20Poly1305Nonce contains a 12-octet nonce. With the 185 CMS, the content-authenticated-encryption key is normally used for a 186 single content. Within the scope of any content-authenticated- 187 encryption key, the nonce value MUST be unique. That is, the set of 188 nonce values used with any given key MUST NOT contain any duplicate 189 values. 191 4. S/MIME Capabilities Attribute 193 Section 2.5.2 of RFC 5751 [MSG] defines the SMIMECapabilities 194 attribute, which is used to specify a partial list of algorithms that 195 the software announcing the SMIMECapabilities can support. When 196 constructing a CMS signed-data content type, compliant software MAY 197 include the SMIMECapabilities signed attribute to announce support 198 for the AEAD_CHACHA20_POLY1305 algorithm. 200 The SMIMECapability SEQUENCE representing the AEAD_CHACHA20_POLY1305 201 algorithm MUST include the id-alg-AEADChaCha20Poly1305 object 202 identifier in the capabilityID field and MUST omit the parameters 203 field. 205 The DER encoding of a SMIMECapability SEQUENCE is the same as the DER 206 encoding of an AlgorithmIdentifier. The DER encoding for the 207 AEAD_CHACHA20_POLY1305 algorithm in the SMIMECapability SEQUENCE (in 208 hexadecimal) is: 210 30 0c 06 0b 2a 86 48 86 f7 0d 01 09 10 03 ?? 212 {{{ Correct above after IANA assigns the object identifier. }}} 214 5. IANA Considerations 216 IANA is requested to add the following entry in the SMI Security for 217 S/MIME Algorithms (1.2.840.113549.1.9.16.3) registry: 219 TBD1 id-alg-AEADChaCha20Poly1305 [This Document] 221 IANA is requested to add the following entry in the SMI Security for 222 S/MIME Module Identifier (1.2.840.113549.1.9.16.0) registry: 224 TBD2 id-mod-CMS-AEADChaCha20Poly1305 [This Document] 226 6. Security Considerations 228 The CMS AuthEnvelopedData provides all of the tools needed to avoid 229 reuse of the same nonce value under the same key. See the discussion 230 in Section 2 of this document. RFC 7539 [FORIETF] describes the 231 consequences of using a nonce value more than once: 233 Consequences of repeating a nonce: If a nonce is repeated, then 234 both the one-time Poly1305 key and the keystream are identical 235 between the 236 messages. This reveals the XOR of the plaintexts, because the 237 XOR of the plaintexts is equal to the XOR of the ciphertexts. 239 When using AEAD_CHACHA20_POLY1305, the resulting ciphertext is always 240 the same size as the original plaintext. Some other mechanism needs 241 to be used in conjunction with AEAD_CHACHA20_POLY1305 if disclosure 242 of the size of the plaintext is a concern. 244 The amount of encrypted data possible in a single invocation of 245 AEAD_CHACHA20_POLY1305 is 2^32-1 blocks of 64 octets each, because of 246 the size of the block counter field in the ChaCha20 block function. 247 This gives a total of 247,877,906,880 octets, which likely to be 248 sufficient to handle the size of any CMS content type. Note that 249 ciphertext length field in the authentication buffer will accomodate 250 2^64 octets, which is much larger than necessary. 252 The AEAD_CHACHA20_POLY1305 construction is a novel composition of 253 ChaCha20 and Poly1305. A security analysis of this composition is 254 given in [PROCTER]. 256 Implementations must randomly generate content-authenticated- 257 encryption keys. The use of inadequate pseudo-random number 258 generators (PRNGs) to generate cryptographic keys can result in 259 little or no security. An attacker may find it much easier to 260 reproduce the PRNG environment that produced the keys, searching the 261 resulting small set of possibilities, rather than brute force 262 searching the whole key space. The generation of quality random 263 numbers is difficult. RFC 4086 [RANDOM] offers important guidance in 264 this area. 266 7. Acknowledgements 268 Thanks to Jim Schaad, Daniel Migault, Stephen Farrell, Yoav Nir, and 269 Niclas Comstedt for their review and insightful comments. 271 8. Normative References 273 [AUTHENV] Housley, R., "Cryptographic Message Syntax (CMS) 274 Authenticated-Enveloped-Data Content Type", RFC 5083, 275 November 2007. 277 [CMS] Housley, R., "Cryptographic Message Syntax (CMS)", RFC 278 5652, September 2009. 280 [FORIETF] Nir, Y. and A. Langley, "ChaCha20 and Poly1305 for IETF 281 Protocols", RFC 7539, May 2015. 283 [MSG] Ramsdell, B., and S. Turner, "Secure/Multipurpose Internet 284 Mail Extensions (S/MIME) Version 3.2 Message 285 Specification", RFC 5751, January 2010. 287 [STDWORDS] Bradner, S., "Key words for use in RFCs to Indicate 288 Requirement Levels", BCP 14, RFC 2119, March 1997. 290 [X680] ITU-T, "Information technology -- Abstract Syntax Notation 291 One (ASN.1): Specification of basic notation", ITU-T 292 Recommendation X.680, 2015. 294 [X690] ITU-T, "Information technology -- ASN.1 encoding rules: 295 Specification of Basic Encoding Rules (BER), Canonical 296 Encoding Rules (CER) and Distinguished Encoding Rules 297 (DER)", ITU-T Recommendation X.690, 2015. 299 9. Informative References 301 [AEAD] McGrew, D., "An Interface and Algorithms for Authenticated 302 Encryption", RFC 5116, January 2008. 304 [CHACHA] Bernstein, D., "ChaCha, a variant of Salsa20", January 305 2008, 306 . 308 [ESTREAM] Babbage, S., DeCanniere, C., Cantenaut, A., Cid, C., 309 Gilbert, H., Johansson, T., Parker, M., Preneel, B., 310 Rijmen, V., and M. Robshaw, "The eSTREAM Portfolio 311 (rev. 1)", September 2008, 312 . 314 [POLY1305] Bernstein, D., "The Poly1305-AES message-authentication 315 code.", March 2005, 316 . 318 [PROCTER] Procter, G., "A Security Analysis of the Composition of 319 ChaCha20 and Poly1305", August 2014, 320 . 322 [RANDOM] Eastlake, D., Schiller, J., and S. Crocker, "Randomness 323 Recommendations for Security", BCP 106, RFC 4086, June 324 2005. 326 Appendix: ASN.1 Module 328 CMS-AEADChaCha20Poly1305 329 { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) 330 pkcs-9(9) smime(16) modules(0) TBD2 } 332 DEFINITIONS IMPLICIT TAGS ::= BEGIN 334 IMPORTS 335 CONTENT-ENCRYPTION 336 FROM AlgorithmInformation-2009 337 { iso(1) identified-organization(3) dod(6) internet(1) 338 security(5) mechanisms(5) pkix(7) id-mod(0) 339 id-mod-algorithmInformation-02(58) }; 341 -- EXPORTS All 343 AEADContentEncryptionAlgs CONTENT-ENCRYPTION ::= 344 { cea-AEADChaCha20Poly1305, ... } 346 cea-AEADChaCha20Poly1305 CONTENT-ENCRYPTION ::= { 347 IDENTIFIER id-alg-AEADChaCha20Poly1305 348 PARAMS TYPE AEADChaCha20Poly1305Nonce ARE required 349 SMIME-CAPS { IDENTIFIED BY id-alg-AEADChaCha20Poly1305 } } 351 id-alg-AEADChaCha20Poly1305 OBJECT IDENTIFIER ::= 352 { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) 353 pkcs9(9) smime(16) alg(3) TBD1 } 355 AEADChaCha20Poly1305Nonce ::= OCTET STRING (SIZE(12)) 357 END 359 Author's Address 361 Russell Housley 362 Vigil Security, LLC 363 918 Spring Knoll Drive 364 Herndon, VA 20170 365 USA 367 EMail: housley@vigilsec.com