idnits 2.17.00 (12 Aug 2021) /tmp/idnits27696/draft-ietf-curdle-cms-chacha20-poly1305-04.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 (1 December 2016) is 1997 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: 1 June 2017 1 December 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 1 June 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 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 encipher the content 157 located in the AuthEnvelopedData EncryptedContentInfo 158 encryptedContent field and to provide the message authentication code 159 (MAC) located in the AuthEnvelopedData mac field. The ciphertext and 160 the MAC are the two outputs of the AEAD_CHACHA20_POLY1305 Algorithm. 161 Note that the MAC, which is called the authentication tag in 162 [FORIETF], provides integrity protection for both the 163 AuthEnvelopedData authAttrs and the AuthEnvelopedData 164 EncryptedContentInfo encryptedContent. 166 Neither the plaintext content nor the optional AAD inputs need to be 167 padded prior to invoking the AEAD_CHACHA20_POLY1305 algorithm. 169 There is one algorithm identifier for the AEAD_CHACHA20_POLY1305 170 algorithm: 172 id-alg-AEADChaCha20Poly1305 OBJECT IDENTIFIER ::= 173 { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) 174 pkcs9(9) smime(16) alg(3) TBD1 } 176 The AlgorithmIdentifier parameters field MUST be present, and the 177 parameters field must contain a AEADChaCha20Poly1305Nonce: 179 AEADChaCha20Poly1305Nonce ::= OCTET STRING (SIZE(12)) 181 The AEADChaCha20Poly1305Nonce contains a 12-octet nonce. With the 182 CMS, the content-authenticated-encryption key is normally used for a 183 single content. Within the scope of any content-authenticated- 184 encryption key, the nonce value MUST be unique. That is, the set of 185 nonce values used with any given key MUST NOT contain any duplicate 186 values. 188 4. S/MIME Capabilities Attribute 190 Section 2.5.2 of RFC 5751 [MSG] defines the SMIMECapabilities 191 attribute, which is used to specify a partial list of algorithms that 192 the software announcing the SMIMECapabilities can support. When 193 constructing a CMS signed-data content type, compliant software MAY 194 include the SMIMECapabilities signed attribute to announce support 195 for the AEAD_CHACHA20_POLY1305 algorithm. 197 The SMIMECapability SEQUENCE representing the AEAD_CHACHA20_POLY1305 198 algorithm MUST include the id-alg-AEADChaCha20Poly1305 object 199 identifier in the capabilityID field and MUST omit the parameters 200 field. 202 The DER encoding of a SMIMECapability SEQUENCE is the same as the DER 203 encoding of an AlgorithmIdentifier. The DER encoding for the 204 AEAD_CHACHA20_POLY1305 algorithm in the SMIMECapability SEQUENCE (in 205 hexadecimal) is: 207 30 0c 06 0b 2a 86 48 86 f7 0d 01 09 10 03 ?? 209 {{{ Correct above after IANA assigns the object identifier. }}} 211 5. IANA Considerations 213 IANA is requested to add the following entry in the SMI Security for 214 S/MIME Algorithms (1.2.840.113549.1.9.16.3) registry: 216 TBD1 id-alg-AEADChaCha20Poly1305 [This Document] 218 IANA is requested to add the following entry in the SMI Security for 219 S/MIME Module Identifier (1.2.840.113549.1.9.16.0) registry: 221 TBD2 id-mod-CMS-AEADChaCha20Poly1305 [This Document] 223 6. Security Considerations 225 The CMS AuthEnvelopedData provides all of the tools needed to avoid 226 reuse of the same nonce value under the same key. See the discussion 227 in Section 2 of this document. RFC 7539 [FORIETF] describes the 228 consequences of using a nonce value more than once: 230 Consequences of repeating a nonce: If a nonce is repeated, then 231 both the one-time Poly1305 key and the keystream are identical 232 between the 233 messages. This reveals the XOR of the plaintexts, because the 234 XOR of the plaintexts is equal to the XOR of the ciphertexts. 236 When using AEAD_CHACHA20_POLY1305, the resulting ciphertext is always 237 the same size as the original plaintext. Some other mechanism needs 238 to be used in conjunction with AEAD_CHACHA20_POLY1305 if disclosure 239 of the size of the plaintext is a concern. 241 The amount of encrypted data possible in a single invocation of 242 AEAD_CHACHA20_POLY1305 is 2^32-1 blocks of 64 octets each, because of 243 the size of the block counter field in the ChaCha20 block function. 244 This gives a total of 247,877,906,880 octets, which likely to be 245 sufficient to handle the size of any CMS content type. Note that 246 ciphertext length field in the authentication buffer will accomodate 247 2^64 octets, which is much larger than necessary. 249 The AEAD_CHACHA20_POLY1305 construction is a novel composition of 250 ChaCha20 and Poly1305. A security analysis of this composition is 251 given in [PROCTER]. 253 Implementations must randomly generate content-authenticated- 254 encryption keys. The use of inadequate pseudo-random number 255 generators (PRNGs) to generate cryptographic keys can result in 256 little or no security. An attacker may find it much easier to 257 reproduce the PRNG environment that produced the keys, searching the 258 resulting small set of possibilities, rather than brute force 259 searching the whole key space. The generation of quality random 260 numbers is difficult. RFC 4086 [RANDOM] offers important guidance in 261 this area. 263 7. Acknowledgements 265 Thanks to Jim Schaad, Daniel Migault, and Stephen Farrell for their 266 review and insightful comments. 268 8. 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 [MSG] Ramsdell, B., and S. Turner, "Secure/Multipurpose Internet 281 Mail Extensions (S/MIME) Version 3.2 Message 282 Specification", RFC 5751, January 2010. 284 [STDWORDS] Bradner, S., "Key words for use in RFCs to Indicate 285 Requirement Levels", BCP 14, RFC 2119, March 1997. 287 [X680] ITU-T, "Information technology -- Abstract Syntax Notation 288 One (ASN.1): Specification of basic notation", ITU-T 289 Recommendation X.680, 2015. 291 [X690] ITU-T, "Information technology -- ASN.1 encoding rules: 292 Specification of Basic Encoding Rules (BER), Canonical 293 Encoding Rules (CER) and Distinguished Encoding Rules 294 (DER)", ITU-T Recommendation X.690, 2015. 296 9. Informative References 298 [AEAD] McGrew, D., "An Interface and Algorithms for Authenticated 299 Encryption", RFC 5116, January 2008. 301 [CHACHA] Bernstein, D., "ChaCha, a variant of Salsa20", January 302 2008, 303 . 305 [ESTREAM] Babbage, S., DeCanniere, C., Cantenaut, A., Cid, C., 306 Gilbert, H., Johansson, T., Parker, M., Preneel, B., 307 Rijmen, V., and M. Robshaw, "The eSTREAM Portfolio 308 (rev. 1)", September 2008, 309 . 311 [POLY1305] Bernstein, D., "The Poly1305-AES message-authentication 312 code.", March 2005, 313 . 315 [PROCTER] Procter, G., "A Security Analysis of the Composition of 316 ChaCha20 and Poly1305", August 2014, 317 . 319 [RANDOM] Eastlake, D., Schiller, J., and S. Crocker, "Randomness 320 Recommendations for Security", BCP 106, RFC 4086, June 321 2005. 323 Appendix: ASN.1 Module 325 CMS-AEADChaCha20Poly1305 326 { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) 327 pkcs-9(9) smime(16) modules(0) TBD2 } 329 DEFINITIONS IMPLICIT TAGS ::= BEGIN 331 IMPORTS 332 CONTENT-ENCRYPTION 333 FROM AlgorithmInformation-2009 334 { iso(1) identified-organization(3) dod(6) internet(1) 335 security(5) mechanisms(5) pkix(7) id-mod(0) 336 id-mod-algorithmInformation-02(58) }; 338 -- EXPORTS All 340 AEADContentEncryptionAlgs CONTENT-ENCRYPTION ::= 341 { cea-AEADChaCha20Poly1305, ... } 343 cea-AEADChaCha20Poly1305 CONTENT-ENCRYPTION ::= { 344 IDENTIFIER id-alg-AEADChaCha20Poly1305 345 PARAMS TYPE AEADChaCha20Poly1305Nonce ARE required 346 SMIME-CAPS { IDENTIFIED BY id-alg-AEADChaCha20Poly1305 } } 348 id-alg-AEADChaCha20Poly1305 OBJECT IDENTIFIER ::= 349 { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) 350 pkcs9(9) smime(16) alg(3) TBD1 } 352 AEADChaCha20Poly1305Nonce ::= OCTET STRING (SIZE(12)) 354 END 356 Author's Address 358 Russell Housley 359 Vigil Security, LLC 360 918 Spring Knoll Drive 361 Herndon, VA 20170 362 USA 364 EMail: housley@vigilsec.com