idnits 2.17.00 (12 Aug 2021) /tmp/idnits535/draft-ietf-lamps-cms-update-alg-id-protect-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 : ---------------------------------------------------------------------------- -- 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 632 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-04 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 6 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 . . . . . . . . . . . . . . . . . . . . . . . . 9 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 nit: there may be a grammar nit here, relating to the parallelism of 181 "compute the digest of" - I think "the collection of attributes that 182 are signed" should also have an "of" or "digest of" prefix. 184 3.3. RFC 5652, Section 5.6 186 Change the paragraph discussing the signed attributes as follows: 188 OLD: 190 The recipient MUST NOT rely on any message digest values computed 191 by the originator. If the SignedData signerInfo includes 192 signedAttributes, then the content message digest MUST be 193 calculated as described in Section 5.4. For the signature to be 194 valid, the message digest value calculated by the recipient MUST 195 be the same as the value of the messageDigest attribute included 196 in the signedAttributes of the SignedData signerInfo. 198 NEW: 200 The recipient MUST NOT rely on any message digest values computed 201 by the originator. If the SignedData signerInfo includes the 202 signedAttrs field, then the content message digest MUST be 203 calculated as described in Section 5.4, using the same digest 204 algorithm to compute the digest of the encapContentInfo eContent 205 OCTET STRING and the message-digest attribute. For the signature 206 to be valid, the message digest value calculated by the recipient 207 MUST be the same as the value of the messageDigest attribute 208 included in the signedAttrs field of the SignedData signerInfo. 210 3.4. Backward Compatibility Considerations 212 The new requirement introduced above might lead to incompatibility 213 with an implementation that allowed different digest algorithms to be 214 used to compute the digest of the message content and the digest of 215 signed attributes. The signatures produced by such an implementation 216 when two different digest algorithms are used will be considered 217 invalid by an implementation that follows this specification. 218 However, most, if not all, implementations already require the 219 originator to use the same digest algorithm for both operations. 221 3.5. Timestamp Compatibility Considerations 223 The new requirement introduced above might lead to compatibility 224 issues for timestamping systems when the originator does not wish to 225 share the message content with the Time Stamp Authority (TSA) 226 [RFC3161]. In this situation, the originator sends a TimeStampReq to 227 the TSA that includes a MessageImprint, which consists of a digest 228 algorithm identifier and a digest value, then the TSA uses the 229 originator-provided digest in the MessageImprint. 231 When producing the TimeStampToken, the TSA MUST use the same digest 232 algorithm to compute the digest of the encapContentInfo eContent, 233 which is an OCTET STRING that contains the TSTInfo, and the message- 234 digest attribute within the SignerInfo. 236 To ensure that TimeStampToken values that were generated before this 237 update remain valid, no requirement is placed on a TSA to ensure that 238 the digest algorithm for the TimeStampToken matches the digest 239 algorithm for the MessageImprint embedded within the TSTInfo. 241 4. Recommended inclusion of the CMSAlgorithmProtection attribute 243 This section updates [RFC5652] to recommend that the originator 244 include the CMSAlgorithmProtection attribute [RFC6211] whenever 245 signed attributes or authenticated attributes are present. 247 4.1. RFC 5652, Section 14 249 Add the following paragraph as the eighth paragraph in Section 14: 251 ADD: 253 While there are no known algorithm substitution attacks today, the 254 inclusion of the algorithm identifiers used by the originator as a 255 signed attribute or an authenticated attribute makes such an 256 attack significantly more difficult. Therefore, the originator of 257 a signed-data content type that includes signed attributes SHOULD 258 include the CMSAlgorithmProtection attribute [RFC6211] as one of 259 the signed attributes. Likewise, the originator of an 260 authenticated-data content type that includes authenticated 261 attributes SHOULD include the CMSAlgorithmProtection attribute 262 [RFC6211] as one of the authenticated attributes. 264 5. IANA Considerations 266 This document makes no requests of the IANA. 268 6. Security Considerations 270 The security properties of the CMS [RFC5652] signed-data and 271 authenticated-data content types are updated to offer protection for 272 algorithm identifiers, which makes algorithm substitution attacks 273 significantly more difficult. 275 For the signed-data content type, the improvements specified in this 276 document force an attacker to mount a hash algorithm substitution 277 attack on the overall signature, not just on the message digest of 278 the encapContentInfo eContent. 280 Some digital signature algorithms have prevented hash function 281 substitutions by including a digest algorithm identifier as an input 282 to the signature algorithm. As discussed in [HASHID], such a 283 "firewall" may not be effective or even possible with newer signature 284 algorithms. For example, RSASSA-PKCS1-v1_5 [RFC8017] protects the 285 digest algorithm identifier, but RSASSA-PSS [RFC8017] does not. 286 Therefore, it remains important that a signer have a way to signal to 287 a recipient which digest algorithms are allowed to be used in 288 conjunction with the verification of an overall signature. This 289 signaling can be done as part of the specification of the signature 290 algorithm, in an X.509v3 certificate extension [RFC5280], or some 291 other means. The Digital Signature Standard (DSS) [DSS] takes the 292 first approach by requiring the use of an "approved" one-way hash 293 algorithm. 295 For the authenticated-data content type, the improvements specified 296 in this document force an attacker to mount a MAC algorithm 297 substitution attack, which is difficult because the attacker does not 298 know the authentication key. 300 The CMSAlgorithmProtection attribute [RFC6211] offers protection for 301 the algorithm identifiers used in the signed-data and authenticated- 302 data content types. However, no protection is provided for the 303 algorithm identifiers in the enveloped-data, digested-data, or 304 encrypted-data content types. Likewise, The CMSAlgorithmProtection 305 attribute provides no protection for the algorithm identifiers used 306 in the authenticated-enveloped-data content type defined in 307 [RFC5083]. A mechanism for algorithm identifier protection for these 308 content types is work for the future. 310 7. Acknowledgements 312 Many thanks to Jim Schaad and Peter Gutmann; without knowing it, they 313 motivated me to write this document. Thanks to Roman Danyliw, Ben 314 Kaduk, and Peter Yee for their careful review and editorial 315 suggestions. 317 8. References 319 8.1. Normative References 321 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 322 Requirement Levels", BCP 14, RFC 2119, 323 DOI 10.17487/RFC2119, March 1997, 324 . 326 [RFC3161] Adams, C., Cain, P., Pinkas, D., and R. Zuccherato, 327 "Internet X.509 Public Key Infrastructure Time-Stamp 328 Protocol (TSP)", RFC 3161, DOI 10.17487/RFC3161, August 329 2001, . 331 [RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", STD 70, 332 RFC 5652, DOI 10.17487/RFC5652, September 2009, 333 . 335 [RFC6211] Schaad, J., "Cryptographic Message Syntax (CMS) Algorithm 336 Identifier Protection Attribute", RFC 6211, 337 DOI 10.17487/RFC6211, April 2011, 338 . 340 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 341 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 342 May 2017, . 344 8.2. Informative References 346 [DSS] National Institute of Standards and Technology (NIST), 347 "Digital Signature Standard (DSS)", FIPS 348 Publication 186-4, July 2013. 350 [HASHID] Kaliski, B., "On Hash Function Firewalls in Signature 351 Schemes", Lecture Notes in Computer Science, Volume 2271, 352 DOI 10.1007/3-540-45760-7_1, February 2002. 354 [RFC5083] Housley, R., "Cryptographic Message Syntax (CMS) 355 Authenticated-Enveloped-Data Content Type", RFC 5083, 356 DOI 10.17487/RFC5083, November 2007, 357 . 359 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 360 Housley, R., and W. Polk, "Internet X.509 Public Key 361 Infrastructure Certificate and Certificate Revocation List 362 (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, 363 . 365 [RFC6210] Schaad, J., "Experiment: Hash Functions with Parameters in 366 the Cryptographic Message Syntax (CMS) and S/MIME", 367 RFC 6210, DOI 10.17487/RFC6210, April 2011, 368 . 370 [RFC8017] Moriarty, K., Ed., Kaliski, B., Jonsson, J., and A. Rusch, 371 "PKCS #1: RSA Cryptography Specifications Version 2.2", 372 RFC 8017, DOI 10.17487/RFC8017, November 2016, 373 . 375 [SHS] National Institute of Standards and Technology (NIST), 376 "Secure Hash Standard", FIPS Publication 180-4, August 377 2015. 379 Author's Address 381 Russ Housley 382 Vigil Security, LLC 383 516 Dranesville Road 384 Herndon, VA 20170 385 US 387 Email: housley@vigilsec.com