Independent Submission D. Cooley Request for Comments: 9151 NSA Category: Informational April 2022 ISSN: 2070-1721 Commercial National Security Algorithm (CNSA) Suite Profile for TLS and DTLS 1.2 and 1.3 Abstract This document defines a base profile for TLS protocol versions 1.2 and 1.3 as well as DTLS protocol versions 1.2 and 1.3 for use with the US Commercial National Security Algorithm (CNSA) Suite. The profile applies to the capabilities, configuration, and operation of all components of US National Security Systems that use TLS or DTLS. It is also appropriate for all other US Government systems that process high-value information. The profile is made publicly available here for use by developers and operators of these and any other system deployments. Status of This Memo This document is not an Internet Standards Track specification; it is published for informational purposes. This is a contribution to the RFC Series, independently of any other RFC stream. The RFC Editor has chosen to publish this document at its discretion and makes no statement about its value for implementation or deployment. Documents approved for publication by the RFC Editor are not candidates for any level of Internet Standard; see Section 2 of RFC 7841. Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc9151. Copyright Notice Copyright (c) 2022 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. Table of Contents 1. Introduction 2. CNSA 3. Terminology 4. CNSA Suites 4.1. CNSA (D)TLS Key Establishment Algorithms 4.2. CNSA TLS Authentication 5. CNSA Compliance and Interoperability Requirements 5.1. Acceptable Elliptic Curve Cryptography (ECC) Curves 5.2. Acceptable RSA Schemes, Parameters, and Checks 5.3. Acceptable Finite Field Groups 5.4. Certificates 6. (D)TLS 1.2 Requirements 6.1. The "extended_master_secret" Extension 6.2. The "signature_algorithms" Extension 6.3. The "signature_algorithms_cert" Extension 6.4. The CertificateRequest Message 6.5. The CertificateVerify Message 6.6. The Signature in the ServerKeyExchange Message 6.7. Certificate Status 7. (D)TLS 1.3 Requirements 7.1. The "signature_algorithms" Extension 7.2. The "signature_algorithms_cert" Extension 7.3. The "early_data" Extension 7.4. Resumption 7.5. Certificate Status 8. Security Considerations 9. IANA Considerations 10. References 10.1. Normative References 10.2. Informative References Author's Address 1. Introduction This document specifies a profile of TLS version 1.2 [RFC5246] and TLS version 1.3 [RFC8446] as well as DTLS version 1.2 [RFC6347] and DTLS version 1.3 [RFC9147] for use by applications that support the National Security Agency's (NSA) Commercial National Security Algorithm (CNSA) Suite [CNSA]. The profile applies to the capabilities, configuration, and operation of all components of US National Security Systems [SP80059]. It is also appropriate for all other US Government systems that process high-value information. It is made publicly available for use by developers and operators of these and any other system deployments. This document does not define any new cipher suites; instead, it defines a CNSA-compliant profile of TLS and DTLS, and the cipher suites defined in [RFC5288], [RFC5289], and [RFC8446]. This profile uses only algorithms in the CNSA Suite. The reader is assumed to have familiarity with the TLS 1.2 and 1.3 as well as the DTLS 1.2 and 1.3 protocol specifications: [RFC5246], [RFC8446], [RFC6347], and [RFC9147], respectively. All MUST-level requirements from the protocol documents apply throughout this profile; they are generally not repeated. This profile contains changes that elevate some SHOULD-level options to MUST-level; this profile also contains changes that elevate some MAY-level options to SHOULD-level or MUST-level. All options that are not mentioned in this profile remain at their original requirement level. 2. CNSA The National Security Agency (NSA) profiles commercial cryptographic algorithms and protocols as part of its mission to support secure, interoperable communications for US National Security Systems. To this end, it publishes guidance both to assist with the US Government transition to new algorithms and to provide vendors -- and the Internet community in general -- with information concerning their proper use and configuration. Recently, cryptographic transition plans have become overshadowed by the prospect of the development of a cryptographically relevant quantum computer. The NSA has established the CNSA Suite to provide vendors and IT users near-term flexibility in meeting their Information Assurance (IA) interoperability requirements. The purpose behind this flexibility is to avoid having vendors and customers make two major transitions in a relatively short timeframe, as we anticipate a need to shift to quantum-resistant cryptography in the near future. The NSA is authoring a set of RFCs, including this one, to provide updated guidance concerning the use of certain commonly available commercial algorithms in IETF protocols. These RFCs can be used in conjunction with other RFCs and cryptographic guidance (e.g., NIST Special Publications) to properly protect Internet traffic and data- at-rest for US National Security Systems. 3. Terminology 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. "ECDSA" and "ECDH" refer to the use of the Elliptic Curve Digital Signature Algorithm (ECDSA) and Elliptic Curve Diffie Hellman (ECDH), respectively. ECDSA and ECDH are used with the NIST P-384 curve (which is based on a 384-bit prime modulus) and the SHA-384 hash function. Similarly, "RSA" and "DH" refer to Rivest-Shamir-Adleman (RSA) and Finite Field Diffie-Hellman (DH), respectively. RSA and DH are used with a 3072-bit or 4096-bit modulus. When RSA is used for digital signature, it is used with the SHA-384 hash function. Henceforth, this document refers to TLS versions 1.2 and 1.3 and DTLS versions 1.2 and 1.3 collectively as "(D)TLS". 4. CNSA Suites [CNSA] approves the use of both Finite Field and elliptic curve versions of the DH key agreement algorithm as well as RSA-based key establishment. [CNSA] also approves certain versions of the RSA and elliptic curve digital signature algorithms. The approved encryption techniques include the Advanced Encryption Standard (AES) used with a 256-bit key in an Authenticated Encryption with Associated Data (AEAD) mode. In particular, CNSA includes the following: Encryption: AES [AES] (with key size 256 bits), operating in Galois/Counter Mode (GCM) [GCM] Digital Signature: ECDSA [DSS] (using the NIST P-384 elliptic curve) RSA [DSS] (with a modulus of 3072 bits or 4096 bits) Key Establishment (includes key agreement and key transport): ECDH [PWKE-A] (using the NIST P-384 elliptic curve) DH [PWKE-A] (with a prime modulus of 3072 or 4096 bits) RSA [PWKE-B] (with a modulus of 3072 or 4096 bits, but only in (D)TLS 1.2) [CNSA] also approves the use of SHA-384 [SHS] as the hash algorithm for mask generation, signature generation, Pseudorandom Function (PRF) in TLS 1.2 and HMAC-based Key Derivation Function (HKDF) in TLS 1.3. 4.1. CNSA (D)TLS Key Establishment Algorithms The following combination of algorithms and key sizes are used in CNSA (D)TLS: AES with 256-bit key, operating in GCM mode ECDH [PWKE-A] using the Ephemeral Unified Model Scheme with cofactor set to 1 (see Section 6.1.2.2 in [PWKE-A]) TLS PRF/HKDF with SHA-384 [SHS] Or AES with 256-bit key, operating in GCM mode RSA key transport using 3072-bit or 4096-bit modulus [PWKE-B][RFC8017] TLS PRF/HKDF with SHA-384 [SHS] Or AES with 256-bit key, operating in GCM mode DH using dhEphem with domain parameters specified below in Section 5.3 (see Section 6.1.2.1 in [PWKE-A]) TLS PRF/HKDF with SHA-384 [SHS] The specific CNSA-compliant cipher suites are listed in Section 5. 4.2. CNSA TLS Authentication For server and/or client authentication, CNSA (D)TLS MUST generate and verify either ECDSA signatures or RSA signatures. In all cases, the client MUST authenticate the server. The server MAY also authenticate the client, as needed by the specific application. The public keys used to verify these signatures MUST be contained in a certificate (see Section 5.4 for more information). 5. CNSA Compliance and Interoperability Requirements CNSA (D)TLS MUST NOT use TLS versions prior to (D)TLS 1.2 in a CNSA- compliant system. CNSA (D)TLS servers and clients MUST implement and use either (D)TLS version 1.2 [RFC5246] [RFC6347] or (D)TLS version 1.3 [RFC8446] [RFC9147]. 5.1. Acceptable Elliptic Curve Cryptography (ECC) Curves The elliptic curves used in the CNSA Suite appear in the literature under two different names [DSS] [SECG]. For the sake of clarity, both names are listed below: +=======+===========+===========+ | Curve | NIST name | SECG name | +=======+===========+===========+ | P-384 | nistp384 | secp384r1 | +-------+-----------+-----------+ Table 1: Elliptic Curves in CNSA Suite [RFC8422] defines a variety of elliptic curves. CNSA (D)TLS connections MUST use secp384r1 (also called nistp384), and the uncompressed form MUST be used, as required by [RFC8422] and [RFC8446]. Key pairs MUST be generated following Section 5.6.1.2 of [PWKE-A]. 5.2. Acceptable RSA Schemes, Parameters, and Checks [CNSA] specifies a minimum modulus size of 3072 bits; however, only two modulus sizes (3072 bits and 4096 bits) are supported by this profile. For (D)TLS 1.2: For certificate signatures, RSASSA-PKCS1-v1_5 [RFC8017] MUST be supported, and RSASSA-PSS [DSS] SHOULD be supported. For signatures in TLS handshake messages, RSASSA-PKCS1-v1_5 [RFC8017] MUST be supported, and RSASSA-PSS [DSS] SHOULD be supported. For key transport, RSAES-PKCS1-v1_5 [RFC8017] MUST be supported. For (D)TLS 1.3: For certificate signatures, RSASSA-PKCS1-v1_5 [RFC8017] MUST be supported, and RSASSA-PSS [DSS] SHOULD be supported. For signatures in TLS handshake messages, RSASSA-PSS [DSS] MUST be supported. For key transport, TLS 1.3 does not support RSA key transport. For all versions of (D)TLS: RSA exponent e MUST satisfy 2^16. [CNSA] Committee for National Security Systems, "Use of Public Standards for Secure Information Sharing", CNSSP 15, October 2016, . [DSS] National Institute of Standards and Technology, "Digital Signature Standard (DSS)", FIPS PUB 186-4, DOI 10.6028/NIST.FIPS.186-4, July 2013, . [GCM] Dworkin, M., "Recommendation for Block Cipher Modes of Operation: Galois/Counter Mode (GCM) and GMAC", NIST Special Publication 800-38D, DOI 10.6028/NIST.SP.800-38D, November 2007, . [PWKE-A] Barker, E., Chen, L., Roginsky, A., Vassilev, A., and R. Davis, "Recommendation for Pair-Wise Key Establishment Schemes Using Discrete Logarithm Cryptography", NIST Special Publication 800-56A Revision 3, DOI 10.6028/NIST.SP.800-56Ar3, April 2018, . [PWKE-B] Barker, E., Chen, L., Roginsky, A., Vassilev, A., Davis, R., and S. Simon, "Recommendation for Pair-Wise Key Establishment Schemes Using Integer Factorization Cryptography", NIST Special Publication 800-56B Revision 2, DOI 10.6028/NIST.SP.800-56Br2, March 2019, . [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, DOI 10.17487/RFC5246, August 2008, . [RFC5288] Salowey, J., Choudhury, A., and D. McGrew, "AES Galois Counter Mode (GCM) Cipher Suites for TLS", RFC 5288, DOI 10.17487/RFC5288, August 2008, . [RFC5289] Rescorla, E., "TLS Elliptic Curve Cipher Suites with SHA- 256/384 and AES Galois Counter Mode (GCM)", RFC 5289, DOI 10.17487/RFC5289, August 2008, . [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, January 2012, . [RFC7627] Bhargavan, K., Ed., Delignat-Lavaud, A., Pironti, A., Langley, A., and M. Ray, "Transport Layer Security (TLS) Session Hash and Extended Master Secret Extension", RFC 7627, DOI 10.17487/RFC7627, September 2015, . [RFC7919] Gillmor, D., "Negotiated Finite Field Diffie-Hellman Ephemeral Parameters for Transport Layer Security (TLS)", RFC 7919, DOI 10.17487/RFC7919, August 2016, . [RFC8017] Moriarty, K., Ed., Kaliski, B., Jonsson, J., and A. Rusch, "PKCS #1: RSA Cryptography Specifications Version 2.2", RFC 8017, DOI 10.17487/RFC8017, November 2016, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [RFC8422] Nir, Y., Josefsson, S., and M. Pegourie-Gonnard, "Elliptic Curve Cryptography (ECC) Cipher Suites for Transport Layer Security (TLS) Versions 1.2 and Earlier", RFC 8422, DOI 10.17487/RFC8422, August 2018, . [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, . [RFC8603] Jenkins, M. and L. Zieglar, "Commercial National Security Algorithm (CNSA) Suite Certificate and Certificate Revocation List (CRL) Profile", RFC 8603, DOI 10.17487/RFC8603, May 2019, . [RFC9147] Rescorla, E., Tschofenig, H., and N. Modadugu, "The Datagram Transport Layer Security (DTLS) Protocol Version 1.3", RFC 9147, DOI 10.17487/RFC9147, April 2022, . [SHS] National Institute of Standards and Technology (NIST), "Secure Hash Standard (SHS)", DOI 10.6028/NIST.FIPS.180-4, FIPS PUB 180-4, August 2015, . 10.2. Informative References [SECG] Brown, D., "SEC 2: Recommended Elliptic Curve Domain Parameters", Version 2.0, February 2010, . [SP80059] Barker, W., "Guideline for Identifying an Information System as a National Security System", DOI 10.6028/NIST.SP.800-59, NIST Special Publication 800-59, August 2003, . Author's Address Dorothy Cooley National Security Agency Email: decoole@nsa.gov