Commercial National Security Algorithm (CNSA) Suite Profile for TLS and DTLS 1.2 and 1.3

This document specifies a profile of TLS version 1.2 and TLS version 1.3 , as well as DTLS version 1.2 and DTLS version 1.3 for use by applications that support the National Security Agency's (NSA) Commercial National Security Algorithm (CNSA) Suite . The profile applies to the capabilities, configuration, and operation of all components of US National Security Systems . 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 and . 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: , , , and . 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.

The National Security Agency (NSA) profiles commercial cryptographic algorithms and protocols as part of its mission to support secure, interoperable communications for US Government 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. 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. 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 Government National Security Systems.

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

approves the use of both finite field and elliptic curve versions of the DH key agreement algorithm, as well as RSA-based key establishment. 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 (with key size 256 bits), operating in Galois/Counter Mode (GCM) Digital Signature: ECDSA (using the NIST P-384 elliptic curve) RSA (with a modulus of 3072 bits or 4096 bits) Key Establishment (includes key agreement and key transport): ECDH (using the NIST P-384 elliptic curve) DH (with a prime modulus of 3072 or 4096 bits) RSA (with a modulus of 3072 or 4096 bits) also approves the use of SHA-384 for the hash algorithm for mask generation, signature generation, Pseudo Random Function (PRF) in TLS 1.2 and HMAC-based key derivation function (HKDF) in TLS 1.3.

The following combination of algorithms and key sizes are used in CNSA (D)TLS: AES with 256-bit key, operating in GCM mode ECDH using the Ephemeral Unified Model Scheme with cofactor set to 1 (see Section 6.1.2.2 in ) TLS PRF/HKDF with SHA-384 Or AES with 256-bit key, operating in GCM mode RSA key transport using 3072-bit or 4096-bit modulus TLS PRF/HKDF with SHA-384 Or AES with 256-bit key, operating in GCM mode DH using dhEphem with domain parameters specified below (see Section 6.1.2.1 in ) TLS PRF/HKDF with SHA-384 The specific CNSA compliant cipher suites are listed in Section 5.

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.

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 or (D)TLS version 1.3 .

The elliptic curves used in the CNSA Suite appear in the literature under two different names . For the sake of clarity, both names are listed below:

Curve NIST name SECG name -------------------------------- P-384 nistp384 secp384r1 defines a variety of elliptic curves. CNSA (D)TLS connections MUST use secp384r1(24) (also called nistp384) and the uncompressed(0) form MUST be supported, as required by and . Key pairs MUST be generated following Section 5.6.1.2 of .

specifies a minimum modulus size of 3072 bits; however, only two modulus sizes (3072 bits and 4096 bits) are supported by this profile. For authentication, RSASSA-PKCS1-v1.5 MUST be supported, and RSASSA-PSS SHOULD be supported. For key transport, RSAES-PKCS1-v1.5 MUST be supported. RSA exponent e MUST satisfy 2^16<e<2^256 and be odd per . If RSASSA-PSS is supported, then the implementation MUST assert rsaEncryption as the public key algorithm, the hash algorithm (used for both mask generation and signature generation) MUST be SHA-384, the mask generation function 1 (MGF1) from MUST be used, and the salt length MUST be 48 octets.

specifies a minimum modulus size of 3072 bits; however, only two modulus sizes (3072 bits and 4096 bits) are supported by this profile. Ephemeral key pairs MUST be generated following Section 5.6.1.1.1 of using the approved safe prime groups specified in for DH ephemeral key agreement. The named groups are: ffdhe3072 (ID=257) ffdhe4096 (ID=258)

Certificates used to establish a CNSA (D)TLS connection MUST be signed with ECDSA or RSA and MUST be compliant with the "CNSA Certificate and Certificate Revocation List (CRL) Profile" .

The CNSA (D)TLS 1.2 client MUST offer at least one of these ciphersuites: TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 TLS_RSA_WITH_AES_256_GCM_SHA384 TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 The CNSA cipher suites listed above MUST be the first (most preferred) cipher suites in the ClientHello message. A CNSA (D)TLS client that offers interoperability with servers that are not CNSA compliant MAY offer additional cipher suites, but any additional cipher suites MUST appear after the CNSA cipher suites in the ClientHello message. A CNSA (D)TLS server MUST accept one of the CNSA suites above if they are offered in the ClientHello message.

A CNSA (D)TLS client MUST include the "signature_algorithms" extension. A CNSA (D)TLS client MUST offer a "signature_algorithms" extension with either signature=ecdsa and hash=SHA384 or signature=rsa and hash=sha384. Following the guidance in , CNSA (D)TLS servers MUST only accept ECDSA or RSA for certification path validation. Other offerings MAY be included to indicate the acceptable signature algorithms in cipher suites that are offered for interoperability with servers not compliant with CNSA and to indicate the signature algorithms that are acceptable for certification path validation in non-compliant CNSA (D)TLS connections.

A CNSA (D)TLS server MUST include ECDSA and SHA-384 and/or RSA and SHA-384 in the supported_signature_algorithms field.

A CNSA (D)TLS server MUST use ECDSA or RSA in the CertificateVerify message. A CNSA (D)TLS client MUST use ECDSA or RSA.

A CNSA (D)TLS server MUST sign the ServerKeyExchange message using ECDSA or RSA.

The client SHOULD request and the server SHOULD provide OSCP responses in the "CertificateEntry".

The CNSA (D)TLS client MUST offer the following CipherSuite in the ClientHello: TLS_AES_256_GCM_SHA384 The CNSA (D)TLS client MUST offer at least one of the following values in the "signature_algorithms" and "signature_algorithms_cert" (optional) extensions: ecdsa_secp384r1_sha384 rsa_pkcs1_sha384 And, if supported, SHOULD offer: rsa_pss_pss_sha384 The CNSA (D)TLS client MUST include at least one of the following values in "supported_groups": ECDHE: secp384r1 DHE: ffdhe3072 DHE: ffdhe4096 The CNSA cipher suite MUST be the first (most preferred) cipher suites in the ClientHello message and in the extensions. A CNSA (D)TLS client that offers interoperability with servers that are not CNSA compliant MAY offer additional cipher suites, but any additional cipher suites MUST appear after the CNSA compliant cipher suites in the ClientHello message. A CNSA (D)TLS server MUST accept one of the CNSA algorithms listed above if they are offered in the ClientHello message.

A CNSA (D)TLS client MUST include the "signature_algorithms" extension. A CNSA (D)TLS client MAY include the "signature_algorithms_cert" extension. A CNSA (D)TLS client MUST offer ECDSA with SHA-384 and/or RSA with SHA-384 in the "signature_algorithms" and "signature_algorithm_cert" extensions. Following the guidance in , CNSA (D)TLS servers MUST only accept ECDSA or RSA for signature path validation. Other offerings MAY be included to indicate the acceptable signature algorithms in cipher suites that are offered for interoperability with servers not compliant with CNSA and to indicate the signature algorithms that are acceptable for certification path validation in non-compliant CNSA (D)TLS connections.

A CNSA (D)TLS client or server MUST NOT include the "early_data" extension. See Section 2.3 for security concerns.

A CNSA (D)TLS server MAY send a CNSA (D)TLS client a NewSessionTicket extension to enable resumption. A CNSA (D)TLS client MUST request "psk_dhe_ke" via the psk_key_exchange_modes ClientHello extension to resume a session. A CNSA (D)TLS client MUST offer ECDHE with SHA-384, RSA with SHA-384 and/or DHE with SHA-384 in the "psk_key_exchange_modes" extension.

The client SHOULD request and the server SHOULD provide OCSP responses in the "CertificateEntry".

Most of the security considerations for this document are described in , , , and . In addition, the security consideration for ECC related to TLS are described in , and . Readers should consult those documents. In order to meet the goal of a consistent security level for the entire cipher suite, CNSA (D)TLS implementations MUST only use the Elliptic Curves, RSA schemes and Finite Fields defined in , , and . Otherwise, it is possible to have a set of symmetric algorithms with much weaker security properties than the asymmetric algorithms. As noted in TLS version 1.3 , TLS does not provide inherent replay protections for early data. For this reason, this profile forbids the use of early data.

This document has no IANA actions.