Commercial National Security Algorithm (CNSA) Suite 2.0 Profile for TLS 1.3

Introduction This document specifies a profile of TLS 1.3 to comply with the National Security Agency's (NSA) Commercial National Security Algorithm (CNSA) 2.0 Suite . This profile applies to the capabilities, configuration, and operation of all components of US National Security Systems (NSS) that employ TLS 1.3. This profile is also appropriate for all other US Government systems that process high-value information, and is made publicly available for use by developers and operators of these and any other system deployments. This document does not define any cryptographic algorithm, and does not specify how to use any cryptographic algorithm not currently supported by TLS 1.3; instead, it profiles CNSA 2.0-compliant conventions for TLS 1.3, and uses algorithms already specified for use in TLS 1.3 that are also allowed by the CNSA Suite 2.0. This document applies to all CNSA Suite solutions that make use of TLS 1.3. The reader is assumed to have familiarity with . This memo is not an IETF standard, and has not been shown to have IETF community consensus. This document obsoletes the CSNA 1.0 guidance in for TLS 1.3. Servers and clients that also support TLS 1.2 (such as, during transition) MUST continue to comply with that guidance.

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 when, and only when, they appear in all capitals, as shown here. Normative language does not apply beyond the scope of this profile. This is a profile of TLS 1.3 . Therefore, the requirements language in this memo may be different than that found in the underlying standards. All references to "CNSA" in this document refer to CNSA 2.0 , unless stated otherwise.

The Commercial National Security Algorithm Suite 2.0 The CNSA Suite is the set of approved commercial algorithms that can be used by vendors and IT users to meet cybersecurity and interoperability requirements for NSS. The initial suite of CNSA Suite algorithms, Suite B, established a baseline for use of commercial algorithms to protect classified information. The following suite, CNSA 1.0, served as a bridge between the original set and a fully quantum-resistant cryptographic capability. The current suite, CNSA 2.0, seeks to provide fully quantum-resistant protection . This profile uses CNSA 2.0 compliant algorithms: ML-DSA-87 for signing, and ML-KEM-1024 for key establishment. ML-DSA-87 and ML-KEM-1024 together with SHA-384, SHA-512, AES-256, LMS, and XMSS comprise the CNSA Suite 2.0. The NSA is authoring a set of RFCs, including this one, to provide updated guidance for using the CNSA 2.0 Suite in certain 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 NSS.

CNSA 2.0 Suite CNSA requires the following algorithms for use in TLS 1.3: Encryption: AES with 256-bit keys, operating in Galois Counter Mode (GCM) ({0x13, 0x02} Appendix B.4 ) Key Establishment: ML-KEM-1024 ({0x0202} MLKEM1024) Digital Signature ML-DSA-87 ({0x0906} MLDSA87) The ML-DSA algorithm incorporates an internal hashing function, so there is no need to apply a hashing algorithm before signing. Where an application or implementation makes it more efficient to perform hashing externally, the external-μ mechanism described in Step 6 of Algorithm 7 of and Section 8 of MAY be used. HashML-DSA is not permitted. CNSA requires the use of SHA-384 for the HMAC-based Key Derivation Function (HKDF) in TLS 1.3.

Compliance and Interoperability In some situations, clients or servers configured for CNSA compliance also have to interoperate with non-compliant clients and servers. Compliant clients and servers MUST be configured such that CNSA compliance is preferred even if it is not intended or expected. CNSA-compliant implementations MUST present CNSA compliant algorithms first in the appropriate extensions, and CNSA-compliant algorithms MUST be used when supported by the peer. If any aspect of CNSA compliance is not achieved, the connection is not CNSA compliant. Any connection negotiated to TLS version 1.2 or lower cannot be CNSA compliant. If interoperability with non-CNSA-compliant clients or servers is not intended, then the session MUST fail if any aspect of CNSA compliance is not achieved.

TLS Version CNSA TLS clients and servers MUST negotiate TLS version 1.3 when establishing a CNSA-compliant connection. CNSA TLS clients and CNSA TLS servers MUST NOT negotiate TLS versions prior to TLS 1.3 in a CNSA-compliant mode.

"supported_versions" Extension A CNSA TLS client connecting to a CNSA TLS server MUST include the "supported_versions" extension in the ClientHello (Section 4.2.1 of ) and list TLS 1.3 version value (0x0304) first in the extension.

Key Exchange Messages This section details requirements for CNSA 2.0-compliant algorithm negotiation in TLS 1.3.

Cipher Suite Negotiation A CNSA TLS client MUST offer the following cipher suite in the ClientHello: TLS_AES_256_GCM_SHA384 {0x13, 0x02} (Appendix B.4 ) This CNSA cipher suite MUST be the first (most preferred) cipher suite in the ClientHello message and in the extensions. A CNSA TLS server MUST select this cipher suite if offered by the client. Any cipher suite other than TLS_AES_256_GCM_SHA384 offered by the client MUST NOT be accepted by a CNSA TLS server establishing a CNSA-compliant connection.

KEM Requirements CNSA 2.0 requires the use of ML-KEM-1024 for key establishment in TLS.

"supported_groups" Extension A CNSA TLS client MUST offer the following value in named_group_list of the "supported_groups" extension (Section 4.2.7 ) of the ClientHello: ML-KEM-1024 {0x0202} ML-KEM-1024 MUST be the first (most preferred) item in named_group_list. A CNSA TLS server MUST select ML-KEM-1024 if it is included in the "supported_groups" extension sent by a CNSA TLS client in the ClientHello. Any algorithm other than ML-KEM-1024 offered by the client MUST NOT be accepted by a CNSA TLS server establishing a CNSA-compliant connection.

"key_share" Extension The "key_share" extension in a CNSA TLS client ClientHello MUST contain the ML-KEM-1024 public key . The ML-KEM-1024 public key must be the first (most preferred) key in the list of key shares. A CNSA TLS server MUST select the ML-KEM-1024 key share for key establishment, and the "key_share" extension in a CNSA TLS server ServerHello MUST contain the ML-KEM-1024 ciphertext associated to the public key provided in the ClientHello .

Authentication Messages A CNSA TLS client MUST require the server to authenticate itself. In all cases, a CNSA TLS client MUST authenticate the server using X.509 certificates; PSK-based authentication MAY be used in addition to certificate-based authentication as detailed in Section 7. A CNSA TLS server MAY also authenticate the client as needed by the specific application. If mutual authentication is desired, X.509 certificates MUST be used in all cases.

"signature_algorithms" Extension A CNSA TLS client MUST offer the following value in the "signature_algorithms" extension of the ClientHello: ML-DSA-87 {0x0906} The ML-DSA-87 algorithm must be the first (most preferred) value in the extension. Any signature algorithm values offered other than ML-DSA-87 MUST NOT be accepted by a CNSA TLS server establishing a CNSA-compliant connection.

"signature_algorithms_cert" Extension Per , the "signature_algorithms_cert" extension applies to signatures in certificates, while the "signature_algorithms" extension (Section 6.1) applies to signatures in CertificateVerify messages. The "signature_algorithms_cert" extension is not required for a CNSA-compliant connection, as ML-DSA-87 is the only allowed signature algorithm that can be used for both signatures in the certificate and in the CertificateVerify message under CNSA compliance. However, if the "signature_algorithms_cert" extension is included, the CNSA TLS client MUST offer the following value first in the "supported_signature_algorithms" field of the extension: ML-DSA-87 {0x0906} Any signature algorithm offered other than ML-DSA-87 MUST NOT be accepted by a CNSA TLS server establishing a CNSA-compliant connection.

CertificateRequest Message A CNSA TLS server MAY authenticate the client as needed by the specific application. If the CNSA TLS server requires mutual authentication, it MUST authenticate the client using X.509 certificates. The "signature_algorithms" extension sent by the CNSA TLS server in the CertificateRequest message MUST include: ML-DSA-87 {0x0906} The "signature_algorithms_cert" extension is not required, but if it is included by the CNSA TLS server in the CertificateRequest message, then it MUST include: ML-DSA-87 {0x0906} ML-DSA-87 MUST be the first (most preferred) algorithm in the "signature_algorithms" and "signature_algorithms_cert" extensions.

Certificate Selection Certificates sent by a CNSA TLS server (and CNSA TLS client, when required) MUST be signed by ML-DSA-87, and MUST be compliant with the CNSA Certificate and Certificate Revocation List Profile . If the client cannot validate the server certificate for any reason, it must abort the handshake. If a CNSA TLS server sends a CertificateRequest message to the client, the client MUST respond with a valid X.509 certificate suitable for authenticating the client. If the CNSA TLS client sends an empty Certificate message, the CNSA TLS server MUST abort the handshake (Section 4.4.2.4 of ). Also, if some aspect of the certificate chain was unacceptable (e.g., it was not signed by a known, trusted CA), the server MUST abort the handshake.

CertificateVerify Message A CNSA TLS client or CNSA TLS server MUST use ML-DSA-87 when sending the CertificateVerify message. CNSA TLS clients or servers MUST accept only ML-DSA-87 in the CertificateVerify message when establishing a CNSA-compliant connection.

External Pre-Shared Keys RFC 8773 specifies an extension that allows an external PSK to be used for authentication in addition to (and not in lieu of) certificate-based authentication during the initial handshake. The PSK also contributes to the TLS 1.3 key schedule (Section 7.1, ). PSK-only authentication is not compliant beyond resumption as covered in . A CNSA TLS client that supports RFC 8773 MUST include the "tls_cert_with_extern_psk" extension (Section 4, ) in the ClientHello message if it desires an external PSK to be used for authentication with certificate-based authentication. This extension is accompanied by the "key_share", "psk_key_exchange_modes", and "pre_shared_key" extensions defined in (Section 4.2.9 and 4.2.11, respectively, of ). The "psk_key_exchange_modes" extension MUST NOT include psk_ke mode. The "psk_key_exchange_modes" extension MUST be psk_dhe_key using ML-KEM-1024. PSKs shall be at least 256 bits in length and generated from a NIST approved random bit generator that supports 256-bits of entropy . If the CNSA TLS server recognizes the "tls_cert_with_extern_psk" extension and possesses at least one of the external PSKs offered by the client in the "pre_shared_key" extension in the ClientHello, then the CNSA TLS server MUST select a CNSA compliant PSK and respond with the "tls_cert_with_extern_psk", "key_share", and "pre_shared_key" extensions in the ServerHello message (Section 4, ).

Resumption A CNSA TLS server MAY send a CNSA TLS client a NewSessionTicket message to enable resumption. A CNSA TLS client MUST request "psk_dhe_ke" via the "psk_key_exchange_modes" extension in the ClientHello to resume a session. The "supported_groups" and "key_share" extensions MUST comply with those detailed in Section 5.2.1 and Section 5.2.2 of this document, respectively.

Certificate Status A CNSA TLS server (and CNSA TLS client, if client authentication is required) MUST provide certificate status information either via a Certificate Revocation List (CRL) distribution points or by the Online Certificate Status Protocol (OCSP) (with or without stapling). For details on CNSA requirements for these methods, see .

"early_data" Extension A CNSA TLS client or server MUST NOT include the "early_data" extension.

DTLS 1.3 CNSA DTLS clients and servers MUST negotiate DTLS version 1.3, when establishing a CNSA-compliant connection. DTLS 1.3, 0xfefc, MUST be listed first in the "supported _versions" extension sent by the CNSA DTLS client. CNSA DTLS clients and CNSA DTLS servers MUST NOT negotiate DTLS versions prior to DTLS 1.3 in a CNSA-compliant mode. A CNSA DTLS client MUST offer the cipher suite TLS_AES_256_GCM_SHA384 {0x13, 0x02} as the first (most preferred) cipher suite in the ClientHello message. For key establishment, CNSA DTLS clients and servers MUST negotiate use of ML-KEM-1024 {0x0202} . For authentication, CNSA DTLS clients and servers MUST negotiate use of ML-DSA-87 as the signature algorithm used in the "signature_algorithms" extension (and the "signature_algorithms_cert" extension, if present). DTLS implementations MUST be consistent with the requirements of TLS defined in this document, except as specified in this section.

Security Considerations Most of the security considerations for this document are described in , . 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.

IANA Considerations This document has no IANA considerations.