Limited Additional Mechanisms for PKIX and SMIME D. Van Geest Internet-Draft CryptoNext Security Intended status: Standards Track F. Strenzke Expires: 8 June 2025 MTG AG 5 December 2024 EUF-CMA for the Cryptographic Message Syntax (CMS) SignedData draft-vangeest-lamps-cms-euf-cma-signeddata-00 Abstract The Cryptographic Message Syntax (CMS) has different signature verification behaviour based on whether signed attributes are present or not. This results in a potential existential forgery vulnerability in CMS and protocols which use CMS. This document describes the vulnerability and lists a number of potential mitigations for LAMPS working group discussion. About This Document This note is to be removed before publishing as an RFC. The latest revision of this draft can be found at https://danvangeest.github.io/cms-euf-cma-signeddata/draft-vangeest- lamps-cms-euf-cma-signeddata.html. Status information for this document may be found at https://datatracker.ietf.org/doc/draft- vangeest-lamps-cms-euf-cma-signeddata/. Discussion of this document takes place on the Limited Additional Mechanisms for PKIX and SMIME Working Group mailing list (mailto:spasm@ietf.org), which is archived at https://mailarchive.ietf.org/arch/browse/spasm/. Subscribe at https://www.ietf.org/mailman/listinfo/spasm/. Source for this draft and an issue tracker can be found at https://github.com/danvangeest/cms-euf-cma-signeddata. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Van Geest & Strenzke Expires 8 June 2025 [Page 1] Internet-Draft EUF-CMA for CMS SignedData December 2024 Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on 8 June 2025. Copyright Notice Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/ license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Conventions and Definitions . . . . . . . . . . . . . . . . . 4 3. Potential Mitigations . . . . . . . . . . . . . . . . . . . . 4 3.1. Immediate Forced Use of Specific Signature Context Strings . . . . . . . . . . . . . . . . . . . . . . . . . 4 3.2. Attribute-Specified Use of Implicit Signature Context Strings . . . . . . . . . . . . . . . . . . . . . . . . . 5 3.2.1. Signing . . . . . . . . . . . . . . . . . . . . . . . 5 3.2.2. Verifying . . . . . . . . . . . . . . . . . . . . . . 5 3.3. Attribute-Specified Use of Explicit Signature Context Strings . . . . . . . . . . . . . . . . . . . . . . . . . 6 4. Straw Mitigations . . . . . . . . . . . . . . . . . . . . . . 8 4.1. Attack Detection in CMS . . . . . . . . . . . . . . . . . 8 4.2. Always/Never use SignedAttributes in Your Protocol . . . 8 4.3. Attack Detection in Your Protocol . . . . . . . . . . . . 9 5. Security Considerations . . . . . . . . . . . . . . . . . . . 9 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 7.1. Normative References . . . . . . . . . . . . . . . . . . 9 7.2. Informative References . . . . . . . . . . . . . . . . . 10 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 11 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 Van Geest & Strenzke Expires 8 June 2025 [Page 2] Internet-Draft EUF-CMA for CMS SignedData December 2024 1. Introduction The Cryptographic Message Syntax (CMS) [RFC5652] signed-data content type allows any number of signers in parallel to sign any type of content. CMS gives a signer two options when generating a signature on some content: * Generate a signature on the whole content; or * Compute a hash over the content, place this hash in the message- digest attribute in the SignedAttributes type, and generate a signature on the SignedAttributes. The resulting signature does not commit to the presence of the SignedAttributes type, allowing an attacker to influence verification behaviour. An attacker can perform two different types of attacks: 1. Take an arbitrary CMS signed message M which was originally signed with SignedAttributes present and remove the SignedAttributes, thereby crafting a new message M' that was never signed by the signer. M' has the DER-encoded SignedAttributes of the original message as its content and verifies correctly against the original signature of M. 2. Let the signer sign a message of the attacker's choice without SignedAttributes. The attacker chooses this message to be a valid DER-encoding of a SignedAttributes object. He can then add this encoded SignedAttributes object to the signed message and change the signed message to the one that was used to create the messageDigest attribute within the SignedAttributes. The signature created by the signer is valid for this arbitrary attacker-chosen message. This vulnerability was presented by Falko Strenzke at IETF 121 [LAMPS121] and is detailed in [Str23]. Due to the limited flexibility of either the signed or the forged message in either attack variant, the fraction of vulnerable systems can be assumed to be small. But due to the wide deployment of the affected protocols, such instances cannot be excluded. Van Geest & Strenzke Expires 8 June 2025 [Page 3] Internet-Draft EUF-CMA for CMS SignedData December 2024 2. Conventions and Definitions The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. 3. Potential Mitigations Potential mitigations are described in the following sub-sections as input to the working group discussion. If this draft is adopted and the working group has taken a decision which measure(s) should be realized, we'll describe the chosen measures in detail. The mitigations in this section make use of a context string which is passed to the signature algorithm's sign and verify functions. ML-DSA [FIPS204], SLH-DSA [FIPS205], Composite ML-DSA [I-D.ietf-lamps-pq-composite-sigs], and Ed448 [RFC8032] take a context string during signing and verification. The context string may be up to 255 bytes long. By default the context string is the empty string. Sign(sk, M, ctx="") Verify(sk, M, ctx="") RSA, ECDSA and Ed25519 signatures do not take a context string and would not be helped by these mitigations. Ed448 can take a context string but does not currently in CMS [RFC8419]. Ed25519ctx [RFC8032] takes a context string but is not specified for use in CMS. 3.1. Immediate Forced Use of Specific Signature Context Strings Immediately update [I-D.ietf-lamps-cms-ml-dsa], [I-D.ietf-lamps-cms-sphincs-plus], and [I-D.ietf-lamps-pq-composite-sigs] to require a context string, with a different value for use with and without signated attributes. When signed attributes are present: Sign(sk, M, "signed-attributes") Verify(sk, M, "signed-attributes") Van Geest & Strenzke Expires 8 June 2025 [Page 4] Internet-Draft EUF-CMA for CMS SignedData December 2024 When signed attributes are absent: Sign(sk, M, "no-signed-attributes") Verify(sk, M, "no-signed-attributes") Unlike the following mitigations, Ed448 cannot be addressed by this mitigation because it is already published and in use. 3.2. Attribute-Specified Use of Implicit Signature Context Strings Like Section 3.1, but the use of the signature context string is indicated by a new, empty (or attribute value ignored), sign-with- context-implicit unsigned attribute. [I-D.ietf-lamps-cms-ml-dsa], [I-D.ietf-lamps-cms-sphincs-plus], and [I-D.ietf-lamps-pq-composite-sigs] can be published using the default signature context string. ML-DSA, SLH-DSA, Composite-ML-DSA, and Ed448 only use the non-default context string when the new attribute is used. 3.2.1. Signing When signed attributes are present: unsigned-attributes.add(sign-with-context-implicit) Sign(sk, M, "signed-attributes") When signed attributes are absent: unsigned-attributes.add(sign-with-context-implicit) Sign(sk, M, "no-signed-attributes") 3.2.2. Verifying When signed attributes are present: IF unsigned-attributes.contains(sign-with-context-implicit) THEN Verify(sk, M, "signed-attributes") ELSE Verify(sk, M, "") When signed attributes are absent: IF unsigned-attributes.contains(sign-with-context-implicit) THEN Verify(sk, M, "no-signed-attributes") ELSE Verify(sk, M, "") Van Geest & Strenzke Expires 8 June 2025 [Page 5] Internet-Draft EUF-CMA for CMS SignedData December 2024 3.3. Attribute-Specified Use of Explicit Signature Context Strings Like Section 3.2 but the new unsigned attribute (sign-with-context- explict) contains a semi-colon-delimited list of keyword (and optional value) strings. This addresses the possibility of future CMS features that require context parameters. ctx = "[=value1];...;[=value]" The list is ordered alphabetically by type string. This list is validated by the verifier and used as the signature context string. (alternative: the SHA-256 hash of the list is used as the signature context string to avoid it getting too long) A proposed list of initial signature context string keywords follows: Van Geest & Strenzke Expires 8 June 2025 [Page 6] Internet-Draft EUF-CMA for CMS SignedData December 2024 +================+==================+=============================+ | keyword | value | comment | +================+==================+=============================+ | "IETF/CMS" | | REQUIRED to be in the sign- | | | | with-context-implicit | | | | attribute, to differentiate | | | | a signature in CMS from a | | | | signature with the same | | | | private key over some other | | | | data. | +----------------+------------------+-----------------------------+ | "signed-attrs" | | Present if signed | | | | attributes are used, not | | | | present if signed | | | | attributes are not used. | | | | Alternative: always | | | | present, value = 0/1, yes/ | | | | no depending on whether | | | | signed attributes are | | | | present or not. | +----------------+------------------+-----------------------------+ | "app-ctx" | base64( SHA-256( | Allows the protocol using | | | protocol_context | CMS to specify a context. | | | ) ) | SHA-256 is applied so that | | | | the length available to the | | | | protocol context isn't | | | | dependent on the other | | | | context values used in CMS. | | | | (alternative: no SHA-256 | | | | here, apply SHA-256 to the | | | | whole CMS context). | | | | base64-encoding is applied | | | | so the app context doesn't | | | | introduce semi-colons to | | | | mess up CMS' parsing of | | | | this string. | +----------------+------------------+-----------------------------+ Table 1: Potential Context String Keywords When a verifier processes a SignerInfo containing the sign-with- context-explicit attribute, it MUST perform the following consistency checks: * If the "signed-attrs" keyword is present and SignedAttributes is not present in the SignerInfo, fail verification. Van Geest & Strenzke Expires 8 June 2025 [Page 7] Internet-Draft EUF-CMA for CMS SignedData December 2024 * If the "signed-attrs" keyword is not present and SignedAttributes is present in the SignerInfo, fail verification. If the consistency checks pass, the signature is verified using the string in the sign-with-context-explicit attribute as the signature context (alternative: using SHA-256 of the string in the sign-with- context-explicit attribute). When a verifier processes a SignerInfo without the sign-with-context- explicit attribute, they MUST verify the signature using the default signature context value (""). [I-D.ietf-lamps-cms-ml-dsa], [I-D.ietf-lamps-cms-sphincs-plus], and [I-D.ietf-lamps-pq-composite-sigs] can be published using the default signature context string. ML-DSA, SLH-DSA, Composite-ML-DSA, and Ed448 only use the non-default context string when the new attribute is used. 4. Straw Mitigations The following mitigations might not be good ideas but are included just in case there's a seed of genius in them. 4.1. Attack Detection in CMS If SignedAttributes is not present, check if the signed message is a valid DER-encoded SignedAttributes structure and fail if it is. The mandatory contentType and messageDigest attributes, with their respective OIDs, should give a low probability of a legitimate message being flagged. If an application protocol deliberately uses such a signed messages, verification would fail. This mitigation does not address the inverse problem where a protocol doesn't used SignedAttributes but for some reason often sends messages which happen to be formatted like valid SignedAttributes encodings, with attacker-controlled bytes where the message digest attribute would be. 4.2. Always/Never use SignedAttributes in Your Protocol Individually update each protocol which use CMS to always require or forbid signed attributes. Van Geest & Strenzke Expires 8 June 2025 [Page 8] Internet-Draft EUF-CMA for CMS SignedData December 2024 4.3. Attack Detection in Your Protocol Section 4.1 but specified in the protocol that uses CMS rather than CMS itself. 5. Security Considerations TODO Security The vulnerability is not present in systems where the use of SignedAttributes is mandatory, for example: SCEP, Certificate Transparency, RFC 4018 firmware update, German Smart Metering CMS data format. However, this security relies on a correct implementation of the verification routine that ensures the presence of SignedAttributes. The vulnerability is also not present when the message is signed and then encrypted, as the attacker cannot learn the signature. Conceivably vulnerable systems (TODO: describe these better): * Unencrypted firmware update denial of service * Dense message space * Signing unstructured data * External signatures over unstructured data * Systems with permissive parsers 6. IANA Considerations This document has no IANA actions. 7. References 7.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", STD 70, RFC 5652, DOI 10.17487/RFC5652, September 2009, . Van Geest & Strenzke Expires 8 June 2025 [Page 9] Internet-Draft EUF-CMA for CMS SignedData December 2024 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . 7.2. Informative References [FIPS204] "Module-lattice-based digital signature standard", National Institute of Standards and Technology (U.S.), DOI 10.6028/nist.fips.204, August 2024, . [FIPS205] "Stateless hash-based digital signature standard", National Institute of Standards and Technology (U.S.), DOI 10.6028/nist.fips.205, August 2024, . [I-D.ietf-lamps-cms-ml-dsa] S, B., R, A., and D. Van Geest, "Use of the ML-DSA Signature Algorithm in the Cryptographic Message Syntax (CMS)", Work in Progress, Internet-Draft, draft-ietf- lamps-cms-ml-dsa-01, 22 November 2024, . [I-D.ietf-lamps-cms-sphincs-plus] Housley, R., Fluhrer, S., Kampanakis, P., and B. Westerbaan, "Use of the SLH-DSA Signature Algorithm in the Cryptographic Message Syntax (CMS)", Work in Progress, Internet-Draft, draft-ietf-lamps-cms-sphincs-plus-17, 30 November 2024, . [I-D.ietf-lamps-pq-composite-sigs] Ounsworth, M., Gray, J., Pala, M., Klaußner, J., and S. Fluhrer, "Composite ML-DSA For use in X.509 Public Key Infrastructure and CMS", Work in Progress, Internet-Draft, draft-ietf-lamps-pq-composite-sigs-03, 21 October 2024, . [LAMPS121] Strenzke, F., "EUF-CMA for CMS SignedData", 6 November 2024, . [RFC8032] Josefsson, S. and I. Liusvaara, "Edwards-Curve Digital Signature Algorithm (EdDSA)", RFC 8032, DOI 10.17487/RFC8032, January 2017, . Van Geest & Strenzke Expires 8 June 2025 [Page 10] Internet-Draft EUF-CMA for CMS SignedData December 2024 [RFC8419] Housley, R., "Use of Edwards-Curve Digital Signature Algorithm (EdDSA) Signatures in the Cryptographic Message Syntax (CMS)", RFC 8419, DOI 10.17487/RFC8419, August 2018, . [Str23] Strenzke, F., "ForgedAttributes: An Existential Forgery Vulnerability of CMS and PKCS#7 Signatures", 22 November 2023, . Acknowledgments TODO acknowledge. Authors' Addresses Daniel Van Geest CryptoNext Security Email: daniel.vangeest@cryptonext-security.com Falko Strenzke MTG AG Email: falko.strenzke@mtg.de Van Geest & Strenzke Expires 8 June 2025 [Page 11]