Use of ML-KEM in the Cryptographic Message Syntax (CMS)

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/.¶

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 3 September 2024.¶

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

ML-KEM is an IND-CCA2-secure key-encapsulation mechanism (KEM) standardized in [FIPS203] by the US NIST PQC Project [NIST-PQ].¶

Native support for Key Encapsulation Mechanisms (KEMs) was added to CMS in [I-D.ietf-lamps-cms-kemri], which defines the KEMRecipientInfo structure for the use of KEM algorithms for the CMS enveloped-data content type, the CMS authenticated-data content type, and the CMS authenticated-enveloped-data content type. This document specifies the direct use of ML-KEM in the KEMRecipientInfo structure in CMS using each of the three parameter sets from [FIPS203], namely MK-KEM-512, ML-KEM-768, and ML-KEM-1024. It does not address or preclude the use of ML-KEM as part of any hybrid scheme.¶

       (ct, ss) = Encapsulate(pk)

       KEK = KDF(ss)

       WK = WRAP(KEK, CEK)

       ss = Decapsulate(sk, ct)

       KEK = KDF(ss)

       CEK = UNWRAP(KEK, WK)

2. Use of the ML-KEM Algorithm in CMS

The ML-KEM Algorithm MAY be employed for one or more recipients in the CMS enveloped-data content type [RFC5652], the CMS authenticated-data content type [RFC5652], or the CMS authenticated-enveloped-data content type [RFC5083]. In each case, the KEMRecipientInfo [I-D.ietf-lamps-cms-kemri] is used with with the ML-KEM Algorithm to securely transfer the content-encryption key from the originator to the recipient.¶

3. Identifiers

All identifiers used by ML-KEM in CMS are defined elsewhere but reproduced here for convenience:¶

  id-TBD-NIST-KEM OBJECT IDENTIFIER ::= { TBD }

  id-ML-KEM-512 OBJECT IDENTIFIER ::= { id-TBD-NIST-KEM TBD }
  id-ML-KEM-768 OBJECT IDENTIFIER ::= { id-TBD-NIST-KEM TBD }
  id-ML-KEM-1024 OBJECT IDENTIFIER ::= { id-TBD-NIST-KEM TBD }

  hashAlgs OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) country(16)
      us(840) organization(1) gov(101) csor(3) nistAlgorithm(4) 2 }

  id-kmac128 OBJECT IDENTIFIER ::= { hashAlgs 21 }
  id-kmac256 OBJECT IDENTIFIER ::= { hashAlgs 22 }

  aes OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) country(16) us(840)
      organization(1) gov(101) csor(3)_ nistAlgorithms(4) 1 }

  id-aes128-wrap OBJECT IDENTIFIER ::= { aes 5 }
  id-aes256-wrap OBJECT IDENTIFIER ::= { aes 45 }

4. Security Considerations

[EDNOTE: many of the security considerations below apply to ML-KEM in general and are not specific to ML-KEM within CMS. As this document and draft-ietf-lamps-kyber-certificates approach WGLC, the two Security Consideration sections should be harmonized and duplicate text removed.]¶

The Security Considerations section of [I-D.ietf-lamps-kyber-certificates] applies to this specification as well.¶

The ML-KEM variant and the underlying components need to be selected consistent with the desired security level. Several security levels have been identified in the NIST SP 800-57 Part 1 [NIST.SP.800-57pt1r5]. To achieve 128-bit security, ML-KEM-512 SHOULD be used, the key-derivation function SHOULD provide at least 128 bits of security, and the symmetric key-encryption algorithm SHOULD be AES Key Wrap with a 128-bit key. To achieve 192-bit security, ML-KEM-768 SHOULD be used, the key-derivation function SHOULD provide at least 192 bits of security, and the symmetric key-encryption algorithm SHOULD be AES Key Wrap with a 192-bit key or larger. In this case AES Key Wrap with a 256-bit key is typically used because AES-192 is not as commonly deployed. To achieve 256-bit security, ML-KEM-1024 SHOULD be used, the key-derivation function SHOULD provide at least 256 bits of security, and the symmetric key-encryption algorithm SHOULD be AES Key Wrap with a 256-bit key.¶

Provided all inputs are well-formed, the key establishment procedure of ML-KEM will never explicitly fail. Specifically, the ML-KEM.Encaps and ML-KEM.Decaps algorithms from [FIPS203] will always output a value with the same data type as a shared secret key, and will never output an error or failure symbol. However, it is possible (though extremely unlikely) that the process will fail in the sense that ML-KEM.Encaps and ML-KEM.Decaps will produce different outputs, even though both of them are behaving honestly and no adversarial interference is present. In this case, the sender and recipient clearly did not succeed in producing a shared secret key. This event is called a decapsulation failure. Estimates for the decapsulation failure probability (or rate) for each of the ML-KEM parameter sets are provided in Table 1 [EDNOTE: make sure this doesn't change] of [FIPS203] and reproduced here in Table 1.¶

Implementations MUST protect the ML-KEM private key, the key-encryption key, the content-encryption key, message-authentication key, and the content-authenticated-encryption key. Disclosure of the ML-KEM private key could result in the compromise of all messages protected with that key. Disclosure of the key-encryption key, the content- encryption key, or the content-authenticated-encryption key could result in compromise of the associated encrypted content. Disclosure of the key-encryption key, the message-authentication key, or the content-authenticated-encryption key could allow modification of the associated authenticated content.¶

Additional considerations related to key management may be found in [NIST.SP.800-57pt1r5].¶

The security of the ML-KEM Algorithm depends on a quality random number generator. For further discussion on random number generation, see [RFC4086].¶

ML-KEM encapsulation and decapsulation only outputs a shared secret and ciphertext. Implementations SHOULD NOT use intermediate values directly for any purpose.¶

Implementations SHOULD NOT reveal information about intermediate values or calculations, whether by timing or other "side channels", otherwise an opponent may be able to determine information about the keying data and/or the recipient's private key. Although not all intermediate information may be useful to an opponent, it is preferable to conceal as much information as is practical, unless analysis specifically indicates that the information would not be useful to an opponent.¶

Generally, good cryptographic practice employs a given ML-KEM key pair in only one scheme. This practice avoids the risk that vulnerability in one scheme may compromise the security of the other, and may be essential to maintain provable security.¶

Parties MAY gain assurance that implementations are correct through formal implementation validation, such as the NIST Cryptographic Module Validation Program (CMVP) [CMVP].¶

5. IANA Considerations

None.¶

Within the CMS, algorithms are identified by object identifiers (OIDs). All of the OIDs used in this document were assigned in other IETF documents, in ISO/IEC standards documents, by the National Institute of Standards and Technology (NIST).¶

6. Acknowledgements

This document borrows heavily from [I-D.ietf-lamps-rfc5990bis], [FIPS203], and [I-D.kampanakis-ml-kem-ikev2]. Thanks go to the authors of those documents. "Copying always makes things easier and less error prone" - RFC8411.¶

Thanks to Carl Wallace for the detailed review and interoperability testing.¶

Appendix A. ASN.1 Module

[EDNOTE: Do we need an ASN.1 module? We haven't defined any new ASN.1. Yes, see S/MIME ASN.1 changes to composite-kem draft]¶

EDITOR'S NOTE' - TODO
section to be completed

Appendix B. Revision History

[EDNOTE: remove before publishing]¶

• draft-ietf-lamps-cms-kyber-03:¶

  • Switch MTI KDF from HKDF to KMAC.¶

• draft-ietf-lamps-cms-kyber-02:¶

  • Rearrange and rewrite to align with rfc5990bis and I-D.ietf-lamps-cms-kemri¶

  • Move Revision History to end to avoid renumbering later¶

  • Add Security Considerations¶

• draft-ietf-lamps-cms-kyber-01:¶

  • Details of the KEMRecipientInfo content when using Kyber;¶

  • Editorial changes.¶

• draft-ietf-lamps-cms-kyber-00:¶

  • Use of KEMRecipientInfo to communicate algorithm info;¶

  • Editorial changes.¶

Authors' Addresses