idnits 2.17.1 draft-ietf-lamps-cms-update-alg-id-protect-05.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 : ---------------------------------------------------------------------------- -- The draft header indicates that this document updates RFC5652, but the abstract doesn't seem to directly say this. It does mention RFC5652 though, so this could be OK. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (August 27, 2020) is 1331 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) No issues found here. Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group R. Housley 3 Internet-Draft Vigil Security 4 Updates: 5652 (if approved) August 27, 2020 5 Intended status: Standards Track 6 Expires: February 28, 2021 8 Update to the Cryptographic Message Syntax (CMS) for Algorithm 9 Identifier Protection 10 draft-ietf-lamps-cms-update-alg-id-protect-05 12 Abstract 14 This document updates the Cryptographic Message Syntax (CMS) 15 specified in RFC 5652 to ensure that algorithm identifiers in signed- 16 data and authenticated-data content types are adequately protected. 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 https://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 February 28, 2021. 35 Copyright Notice 37 Copyright (c) 2020 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 (https://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 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 53 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 54 3. Required use the same hash algorithm . . . . . . . . . . . . 3 55 3.1. RFC 5652, Section 5.3 . . . . . . . . . . . . . . . . . . 3 56 3.2. RFC 5652, Section 5.4 . . . . . . . . . . . . . . . . . . 4 57 3.3. RFC 5652, Section 5.6 . . . . . . . . . . . . . . . . . . 4 58 3.4. Backward Compatibility Considerations . . . . . . . . . . 5 59 3.5. Timestamp Compatibility Considerations . . . . . . . . . 5 60 4. Recommended inclusion of the CMSAlgorithmProtection attribute 5 61 4.1. RFC 5652, Section 14 . . . . . . . . . . . . . . . . . . 6 62 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 63 6. Security Considerations . . . . . . . . . . . . . . . . . . . 6 64 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7 65 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 66 8.1. Normative References . . . . . . . . . . . . . . . . . . 7 67 8.2. Informative References . . . . . . . . . . . . . . . . . 8 68 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 8 70 1. Introduction 72 This document updates the Cryptographic Message Syntax (CMS) 73 [RFC5652] to ensure that algorithm identifiers in signed-data and 74 authenticated-data content types are adequately protected. 76 The CMS signed-data Content Type [RFC5652], unlike X.509 certificates 77 [RFC5280], can be vulnerable to algorithm substitution attacks. In 78 an algorithm substitution attack, the attacker changes either the 79 algorithm identifier or the parameters associated with the algorithm 80 identifier to change the verification process used by the recipient. 81 The X.509 certificate structure protects the algorithm identifier and 82 the associated parameters by signing them. 84 In an algorithm substitution attack, the attacker looks for a 85 different algorithm that produces the same result as the algorithm 86 used by the originator. As an example, if the signer of a message 87 used SHA-256 [SHS] as the digest algorithm to hash the message 88 content, then the attacker looks for a weaker hash algorithm that 89 produces a result that is of the same length. The attacker's goal is 90 to find a different message that results in the same hash value, 91 which is called a cross-algorithm collision. Today, there are many 92 hash functions that produce 256-bit results. One of them may be 93 found to be weak in the future. 95 Further, when a digest algorithm produces a larger result than is 96 needed by a digital signature algorithm, the digest value is reduced 97 to the size needed by the signature algorithm. This can be done both 98 by truncation and modulo operations, with the simplest being 99 straightforward truncation. In this situation, the attacker needs to 100 find a collision with the reduced digest value. As an example, if 101 the message signer uses SHA-512 [SHS] as the digest algorithm and 102 ECDSA with the P-256 curve [DSS] as the signature algorithm, then the 103 attacker needs to find a collision with the first half of the digest. 105 Similar attacks can be mounted against parameterized algorithm 106 identifiers. When looking at randomized hash functions, such as the 107 example in [RFC6210], the algorithm identifier parameter includes a 108 random value that can be manipulated by an attacker looking for 109 collisions. Some other algorithm identifiers include complex 110 parameter structures, and each value provides another opportunity for 111 manipulation by an attacker. 113 This document makes two updates to CMS to provide protection for the 114 algorithm identifier. First, it mandates a convention followed by 115 many implementations by requiring the originator to use the same hash 116 algorithm to compute the digest of the message content and the digest 117 of signed attributes. Second, it recommends that the originator 118 include the CMSAlgorithmProtection attribute [RFC6211]. 120 2. Terminology 122 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 123 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 124 "OPTIONAL" in this document are to be interpreted as described in 125 BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all 126 capitals, as shown here. 128 3. Required use the same hash algorithm 130 This section updates [RFC5652] to require the originator to use the 131 same hash algorithm to compute the digest of the message content and 132 the digest of signed attributes. 134 3.1. RFC 5652, Section 5.3 136 Change the paragraph describing the digestAlgorithm as follows: 138 OLD: 140 digestAlgorithm identifies the message digest algorithm, and any 141 associated parameters, used by the signer. The message digest is 142 computed on either the content being signed or the content 143 together with the signed attributes using the process described in 144 Section 5.4. The message digest algorithm SHOULD be among those 145 listed in the digestAlgorithms field of the associated SignerData. 147 Implementations MAY fail to validate signatures that use a digest 148 algorithm that is not included in the SignedData digestAlgorithms 149 set. 151 NEW: 153 digestAlgorithm identifies the message digest algorithm, and any 154 associated parameters, used by the signer. The message digest is 155 computed on either the content being signed or the content 156 together with the signedAttrs using the process described in 157 Section 5.4. The message digest algorithm SHOULD be among those 158 listed in the digestAlgorithms field of the associated SignerData. 159 If the signedAttrs field is present in the SignerInfo, then the 160 same digest algorithm MUST be used to compute both the digest of 161 the SignedData encapContentInfo eContent, which is carried in the 162 message-digest attribute, and the digest of the DER-encoded 163 signedAttrs, which is passed to the signature algorithm. 164 Implementations MAY fail to validate signatures that use a digest 165 algorithm that is not included in the SignedData digestAlgorithms 166 set. 168 3.2. RFC 5652, Section 5.4 170 Add the following paragraph as the second paragraph in Section 5.4: 172 ADD: 174 When the signedAttrs field is present, the same digest algorithm 175 MUST be used to compute the digest of the encapContentInfo 176 eContent OCTET STRING, which is carried in the message-digest 177 attribute, and the digest of the collection of attributes that are 178 signed. 180 3.3. RFC 5652, Section 5.6 182 Change the paragraph discussing the signed attributes as follows: 184 OLD: 186 The recipient MUST NOT rely on any message digest values computed 187 by the originator. If the SignedData signerInfo includes 188 signedAttributes, then the content message digest MUST be 189 calculated as described in Section 5.4. For the signature to be 190 valid, the message digest value calculated by the recipient MUST 191 be the same as the value of the messageDigest attribute included 192 in the signedAttributes of the SignedData signerInfo. 194 NEW: 196 The recipient MUST NOT rely on any message digest values computed 197 by the originator. If the SignedData signerInfo includes the 198 signedAttrs field, then the content message digest MUST be 199 calculated as described in Section 5.4, using the same digest 200 algorithm to compute the digest of the encapContentInfo eContent 201 OCTET STRING and the message-digest attribute. For the signature 202 to be valid, the message digest value calculated by the recipient 203 MUST be the same as the value of the messageDigest attribute 204 included in the signedAttrs field of the SignedData signerInfo. 206 3.4. Backward Compatibility Considerations 208 The new requirement introduced above might lead to incompatibility 209 with an implementation that allowed different digest algorithms to be 210 used to compute the digest of the message content and the digest of 211 signed attributes. The signatures produced by such an implementation 212 when two different digest algorithms are used will be considered 213 invalid by an implementation that follows this specification. 214 However, most, if not all, implementations already require the 215 originator to use the same digest algorithm for both operations. 217 3.5. Timestamp Compatibility Considerations 219 The new requirement introduced above might lead to compatibility 220 issues for timestamping systems when the originator does not wish to 221 share the message content with the Time Stamp Authority (TSA) 222 [RFC3161]. In this situation, the originator sends a TimeStampReq to 223 the TSA that includes a MessageImprint, which consists of a digest 224 algorithm identifier and a digest value, then the TSA uses the 225 originator-provided digest in the MessageImprint. 227 When producing the TimeStampToken, the TSA MUST use the same digest 228 algorithm to compute the digest of the encapContentInfo eContent, 229 which is an OCTET STRING that contains the TSTInfo, and the message- 230 digest attribute within the SignerInfo. 232 To ensure that TimeStampToken values that were generated before this 233 update remain valid, no requirement is placed on a TSA to ensure that 234 the digest algorithm for the TimeStampToken matches the digest 235 algorithm for the MessageImprint embedded within the TSTInfo. 237 4. Recommended inclusion of the CMSAlgorithmProtection attribute 239 This section updates [RFC5652] to recommend that the originator 240 include the CMSAlgorithmProtection attribute [RFC6211] whenever 241 signed attributes or authenticated attributes are present. 243 4.1. RFC 5652, Section 14 245 Add the following paragraph as the eighth paragraph in Section 14: 247 ADD: 249 While there are no known algorithm substitution attacks today, the 250 inclusion of the algorithm identifiers used by the originator as a 251 signed attribute or an authenticated attribute makes such an 252 attack significantly more difficult. Therefore, the originator of 253 a signed-data content type that includes signed attributes SHOULD 254 include the CMSAlgorithmProtection attribute [RFC6211] as one of 255 the signed attributes. Likewise, the originator of an 256 authenticated-data content type that includes authenticated 257 attributes SHOULD include the CMSAlgorithmProtection attribute 258 [RFC6211] as one of the authenticated attributes. 260 5. IANA Considerations 262 This document makes no requests of the IANA. 264 6. Security Considerations 266 The security properties of the CMS [RFC5652] signed-data and 267 authenticated-data content types are updated to offer protection for 268 algorithm identifiers, which makes algorithm substitution attacks 269 significantly more difficult. 271 For the signed-data content type, the improvements specified in this 272 document force an attacker to mount a hash algorithm substitution 273 attack on the overall signature, not just on the message digest of 274 the encapContentInfo eContent. 276 Some digital signature algorithms have prevented hash function 277 substitutions by including a digest algorithm identifier as an input 278 to the signature algorithm. As discussed in [HASHID], such a 279 "firewall" may not be effective or even possible with newer signature 280 algorithms. For example, RSASSA-PKCS1-v1_5 [RFC8017] protects the 281 digest algorithm identifier, but RSASSA-PSS [RFC8017] does not. 282 Therefore, it remains important that a signer have a way to signal to 283 a recipient which digest algorithms are allowed to be used in 284 conjunction with the verification of an overall signature. This 285 signaling can be done as part of the specification of the signature 286 algorithm, in an X.509v3 certificate extension [RFC5280], or some 287 other means. The Digital Signature Standard (DSS) [DSS] takes the 288 first approach by requiring the use of an "approved" one-way hash 289 algorithm. 291 For the authenticated-data content type, the improvements specified 292 in this document force an attacker to mount a MAC algorithm 293 substitution attack, which is difficult because the attacker does not 294 know the authentication key. 296 The CMSAlgorithmProtection attribute [RFC6211] offers protection for 297 the algorithm identifiers used in the signed-data and authenticated- 298 data content types. However, no protection is provided for the 299 algorithm identifiers in the enveloped-data, digested-data, or 300 encrypted-data content types. Likewise, The CMSAlgorithmProtection 301 attribute provides no protection for the algorithm identifiers used 302 in the authenticated-enveloped-data content type defined in 303 [RFC5083]. A mechanism for algorithm identifier protection for these 304 content types is work for the future. 306 7. Acknowledgements 308 Many thanks to Jim Schaad and Peter Gutmann; without knowing it, they 309 motivated me to write this document. Thanks to Roman Danyliw, Ben 310 Kaduk, and Peter Yee for their careful review and editorial 311 suggestions. 313 8. References 315 8.1. Normative References 317 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 318 Requirement Levels", BCP 14, RFC 2119, 319 DOI 10.17487/RFC2119, March 1997, 320 . 322 [RFC3161] Adams, C., Cain, P., Pinkas, D., and R. Zuccherato, 323 "Internet X.509 Public Key Infrastructure Time-Stamp 324 Protocol (TSP)", RFC 3161, DOI 10.17487/RFC3161, August 325 2001, . 327 [RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", STD 70, 328 RFC 5652, DOI 10.17487/RFC5652, September 2009, 329 . 331 [RFC6211] Schaad, J., "Cryptographic Message Syntax (CMS) Algorithm 332 Identifier Protection Attribute", RFC 6211, 333 DOI 10.17487/RFC6211, April 2011, 334 . 336 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 337 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 338 May 2017, . 340 8.2. Informative References 342 [DSS] National Institute of Standards and Technology (NIST), 343 "Digital Signature Standard (DSS)", FIPS 344 Publication 186-4, July 2013. 346 [HASHID] Kaliski, B., "On Hash Function Firewalls in Signature 347 Schemes", Lecture Notes in Computer Science, Volume 2271, 348 DOI 10.1007/3-540-45760-7_1, February 2002. 350 [RFC5083] Housley, R., "Cryptographic Message Syntax (CMS) 351 Authenticated-Enveloped-Data Content Type", RFC 5083, 352 DOI 10.17487/RFC5083, November 2007, 353 . 355 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 356 Housley, R., and W. Polk, "Internet X.509 Public Key 357 Infrastructure Certificate and Certificate Revocation List 358 (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, 359 . 361 [RFC6210] Schaad, J., "Experiment: Hash Functions with Parameters in 362 the Cryptographic Message Syntax (CMS) and S/MIME", 363 RFC 6210, DOI 10.17487/RFC6210, April 2011, 364 . 366 [RFC8017] Moriarty, K., Ed., Kaliski, B., Jonsson, J., and A. Rusch, 367 "PKCS #1: RSA Cryptography Specifications Version 2.2", 368 RFC 8017, DOI 10.17487/RFC8017, November 2016, 369 . 371 [SHS] National Institute of Standards and Technology (NIST), 372 "Secure Hash Standard", FIPS Publication 180-4, August 373 2015. 375 Author's Address 377 Russ Housley 378 Vigil Security, LLC 379 516 Dranesville Road 380 Herndon, VA 20170 381 US 383 Email: housley@vigilsec.com