idnits 2.17.00 (12 Aug 2021) /tmp/idnits30439/draft-ietf-curdle-cms-chacha20-poly1305-03.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 (28 October 2016) is 2031 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: 28 April 2017 28 October 2016 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 22 March 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 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 256-bit, single-use key. Poly1305 68 is also described in [FORIETF]. 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 A high-level summary of AEAD_CHACHA20_POLY1305 authenticated 89 encryption processing is: 91 1) A 256-bit Poly1305 one-time key is generated from the input 92 256-bit key and nonce using the procedure described in 93 Section 2.6 of [FORIETF]. 95 2) The ChaCha20 encryption function is used to encrypt the 96 plaintext, using the same 256-bit key and nonce, and with the 97 initial 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 AEAD_CHACHA20_POLY1305 nonce value with the same key 137 destroys the security guarantees. I can be extremely difficult to 138 use a statically configured AEAD_CHACHA20_POLY1305 key and never 139 repeat a nonce value. For safety's sake, implementations MUST use an 140 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. S/MIME Capabilities 221 {{{ This can be written once the Object Identifier is assigned. }}} 223 5. IANA Considerations 225 IANA is requested to add the following entry in the SMI Security for 226 S/MIME Algorithms (1.2.840.113549.1.9.16.3) registry: 228 TBD1 id-alg-AEADChaCha20Poly1305 [This Document] 230 IANA is requested to add the following entry in the SMI Security for 231 S/MIME Module Identifier (1.2.840.113549.1.9.16.0) registry: 233 TBD2 id-mod-CMS-AEADChaCha20Poly1305 [This Document] 235 6. Security Considerations 237 The CMS AuthEnvelopedData provides all of the tools needed to avoid 238 reuse of the same nonce value under the same key. Automated key 239 management is discussed in Section 2. 241 When using AEAD_CHACHA20_POLY1305, the resulting ciphertext is always 242 the same size as the original plaintext. Some other mechanism needs 243 to be used in conjunction with AEAD_CHACHA20_POLY1305 if disclosure 244 of the size of the plaintext is a concern. 246 The amount of encrypted data possible in a single invocation of 247 AEAD_CHACHA20_POLY1305 is 2^32-1 blocks of 64 octets each, because of 248 the size of the block counter field in the ChaCha20 block function. 249 This gives a total of 247,877,906,880 octets, which likely to be 250 sufficient to handle the size of any CMS content type. Note that 251 ciphertext length field in the authentication buffer will accomodate 252 2^64 octets, which is much larger than necessary. 254 The AEAD_CHACHA20_POLY1305 construction is a novel composition of 255 ChaCha20 and Poly1305. A security analysis of this composition is 256 given in [PROCTER]. 258 Implementations must randomly generate content-authenticated- 259 encryption keys. The use of inadequate pseudo-random number 260 generators (PRNGs) to generate cryptographic keys can result in 261 little or no security. An attacker may find it much easier to 262 reproduce the PRNG environment that produced the keys, searching the 263 resulting small set of possibilities, rather than brute force 264 searching the whole key space. The generation of quality random 265 numbers is difficult. RFC 4086 [RANDOM] offers important guidance in 266 this area. 268 7. Acknowledgements 270 Thanks to Jim Schaad and Daniel Migault for their review and 271 insightful comments. 273 8. Normative References 275 [AUTHENV] Housley, R., "Cryptographic Message Syntax (CMS) 276 Authenticated-Enveloped-Data Content Type", RFC 5083, 277 November 2007. 279 [CMS] Housley, R., "Cryptographic Message Syntax (CMS)", RFC 280 5652, September 2009. 282 [FORIETF] Nir, Y. and A. Langley, "ChaCha20 and Poly1305 for IETF 283 Protocols", RFC 7539, May 2015. 285 [STDWORDS] Bradner, S., "Key words for use in RFCs to Indicate 286 Requirement Levels", BCP 14, RFC 2119, March 1997. 288 [X680] ITU-T, "Information technology -- Abstract Syntax Notation 289 One (ASN.1): Specification of basic notation", ITU-T 290 Recommendation X.680, 2015. 292 [X690] ITU-T, "Information technology -- ASN.1 encoding rules: 293 Specification of Basic Encoding Rules (BER), Canonical 294 Encoding Rules (CER) and Distinguished Encoding Rules 295 (DER)", ITU-T Recommendation X.690, 2015. 297 9. Informative References 299 [AEAD] McGrew, D., "An Interface and Algorithms for Authenticated 300 Encryption", RFC 5116, January 2008. 302 [CHACHA] Bernstein, D., "ChaCha, a variant of Salsa20", January 303 2008, 304 . 306 [ESTREAM] Babbage, S., DeCanniere, C., Cantenaut, A., Cid, C., 307 Gilbert, H., Johansson, T., Parker, M., Preneel, B., 308 Rijmen, V., and M. Robshaw, "The eSTREAM Portfolio 309 (rev. 1)", September 2008, 310 . 312 [KEYMGMT] Bellovin, S. and R. Housley, "Guidelines for Cryptographic 313 Key Management", BCP 107, RFC 4107, June 2005. 315 [POLY1305] Bernstein, D., "The Poly1305-AES message-authentication 316 code.", March 2005, 317 . 319 [PROCTER] Procter, G., "A Security Analysis of the Composition of 320 ChaCha20 and Poly1305", August 2014, 321 . 323 [RANDOM] Eastlake, D., Schiller, J., and S. Crocker, "Randomness 324 Recommendations for Security", BCP 106, RFC 4086, June 325 2005. 327 Appendix: ASN.1 Module 329 CMS-AEADChaCha20Poly1305 330 { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) 331 pkcs-9(9) smime(16) modules(0) TBD2 } 333 DEFINITIONS IMPLICIT TAGS ::= BEGIN 335 IMPORTS 336 CONTENT-ENCRYPTION 337 FROM AlgorithmInformation-2009 338 { iso(1) identified-organization(3) dod(6) internet(1) 339 security(5) mechanisms(5) pkix(7) id-mod(0) 340 id-mod-algorithmInformation-02(58) }; 342 -- EXPORTS All 344 AEADContentEncryptionAlgs CONTENT-ENCRYPTION ::= 345 { cea-AEADChaCha20Poly1305, ... } 347 cea-AEADChaCha20Poly1305 CONTENT-ENCRYPTION ::= { 348 IDENTIFIER id-alg-AEADChaCha20Poly1305 349 PARAMS TYPE AEADChaCha20Poly1305Nonce ARE required 350 SMIME-CAPS { IDENTIFIED BY id-alg-AEADChaCha20Poly1305 } } 352 id-alg-AEADChaCha20Poly1305 OBJECT IDENTIFIER ::= 353 { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) 354 pkcs9(9) smime(16) alg(3) TBD1 } 356 AEADChaCha20Poly1305Nonce ::= OCTET STRING (SIZE(12)) 358 END 360 Author's Addresses 362 Russell Housley 363 Vigil Security, LLC 364 918 Spring Knoll Drive 365 Herndon, VA 20170 366 USA 368 EMail: housley@vigilsec.com