| Internet-Draft | CNSA2 TLS Profile | August 2025 |
| Becker | Expires 2 March 2026 | [Page] |
This document defines a base profile of TLS 1.3 for use with the US Commercial National Security Algorithm (CNSA) 2.0 Suite, a cybersecurity advisory published by the United States Government which outlines quantum-resistant cryptographic algorithm policy for US national security applications.¶
This profile applies to the capabilities, configuration, and operation of all components of US National Security Systems that employ TLS 1.3. It is also appropriate for all other US Government systems that process high-value information.¶
This memo is not an IETF standard, and has not been shown to have IETF community consensus. This profile is made publicly available for use by developers and operators of these and any other system deployments.¶
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 2 March 2026.¶
Copyright (c) 2025 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.¶
This document specifies a profile of TLS 1.3 [RFC8446] to comply with the National Security Agency's (NSA) Commercial National Security Algorithm (CNSA) 2.0 Suite [cnsafaq]. This profile applies to the capabilities, configuration, and operation of all components of US National Security Systems (NSS) [SP80059] 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 [RFC8446], [I-D.ietf-tls-mlkem], [I-D.ietf-tls-mldsa], [I-D.ietf-tls-8773bis].¶
This memo is not an IETF standard, and has not been shown to have IETF community consensus.¶
[ED NOTE: This document uses guidance from [I-D.ietf-tls-mlkem], and [I-D.ietf-tls-mldsa] to specify use of ML-KEM and ML-DSA in TLS 1.3, respectively. We note that the drafts are not yet RFCs, and we may need to adjust this text accordingly based on the progress of these documents.]¶
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. Normative language does not apply beyond the scope of this profile.¶
This is a profile of TLS 1.3 [RFC8446]. 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 [cnsafaq], unless stated otherwise.¶
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 [cnsafaq].¶
This profile uses CNSA 2.0 compliant algorithms: ML-DSA-87 [FIPS204] for signing, and ML-KEM-1024 [FIPS203] for key establishment. ML-DSA-87 and ML-KEM-1024 together with SHA384, SHA512, 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.¶
In some situations, clients or servers configured for CNSA compliance may have to interoperate with non-compliant clients and servers. Such 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.¶
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.¶
If TLS version 1.2 or lower is negotiated, the connection cannot be CNSA compliant (Section 4.2).¶
CNSA requires the following algorithms for use in TLS 1.3:¶
Encryption:¶
AES [AES] with 256-bit keys, operating in Galois Counter Mode (GCM) [GCM] ({0x13, 0x02} Appendix B.4 [RFC8446])¶
Key Establishment:¶
ML-KEM-1024 [FIPS203] ({0x0202} MLKEM1024, Section 4.1 of [I-D.ietf-tls-mlkem])¶
Digital Signature¶
ML-DSA-87 [FIPS204] ({0x0906} MLDSA87, Section 3 of [I-D.ietf-tls-mldsa])¶
CNSA requires the use of SHA-384 [SHS] for the HMAC-based Key Derivation Function (HKDF) in TLS 1.3.¶
CNSA TLS clients and servers MUST negotiate TLS version 1.3 [RFC8446] 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.¶
A CNSA TLS client connecting to a CNSA TLS server MUST include the "supported_versions" extension in the ClientHello (Section 4.2.1 of [RFC8446]) and list TLS 1.3 version value (0x0304) first in the extension.¶
A CNSA server establishing a CNSA-compliant connection MUST select TLS 1.3.¶
This section details requirements for CNSA 2.0-compliant algorithm negotiation in TLS 1.3.¶
A CNSA TLS client MUST offer the following cipher suite in the ClientHello:¶
TLS_AES_256_GCM_SHA384 {0x13, 0x02} (Appendix B.4 [RFC8446])¶
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.¶
CNSA 2.0 requires the use of ML-KEM-1024 for key establishment in TLS.¶
A CNSA TLS client MUST offer the following value in named_group_list of the "supported_groups" extension (Section 4.2.7 [RFC8446]) of the ClientHello:¶
ML-KEM-1024 {0x0202} (Section 4.1 [I-D.ietf-tls-mlkem])¶
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.¶
In order to facilitate use of a KEM, the public key and ciphertext are sent via the "key_share" extension in the ClientHello and ServerHello, respectively [I-D.ietf-tls-mlkem]. Specifically, the public key, generated from the ML-KEM-1024 KeyGen algorithm is sent by the client in the KeyShareClientHello value of the extension_data field in the "key_share" extension. The KEM ciphertext generated from the ML-KEM-1024 Encaps algorithm is then transmitted from the server back to the client via the KeyShareServerHello value of the extension_data field of the extension.¶
[ED NOTE: Much of this guidance is written in [I-D.ietf-tls-mlkem] but as it's in draft form, we rewrite here for clarity.]¶
The "key_share" extension in a CNSA TLS client ClientHello MUST contain the ML-KEM-1024 public key (Section 4.2, [I-D.ietf-tls-mlkem]).¶
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 (Section 4.2, [I-D.ietf-tls-mlkem]).¶
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.¶
A CNSA TLS client MUST offer the following value in the "signature_algorithms" extension of the ClientHello:¶
ML-DSA-87 {0x0906} (Section 3 [I-D.ietf-tls-mldsa])¶
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.¶
Per [RFC8446], 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} (Section 3 [I-D.ietf-tls-mldsa])¶
Any signature algorithm offered other than ML-DSA-87 MUST NOT be accepted by a CNSA TLS server establishing a CNSA-compliant connection.¶
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} (Section 3 [I-D.ietf-tls-mldsa])¶
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} (Section 3 [I-D.ietf-tls-mldsa])¶
ML-DSA-87 MUST be the first (most preferred) algorithm in the "signature_algorithms" and "signature_algorithms_cert" extensions.¶
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 [I-D.jenkins-cnsa2-pkix-profile].¶
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 [RFC8446]). 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.¶
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.¶
RFC 8773 [I-D.ietf-tls-8773bis] 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, [RFC8446]).¶
A CNSA TLS client that supports RFC 8773 MUST include the "tls_cert_with_extern_psk" extension (Section 4, [I-D.ietf-tls-8773bis]) 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 [RFC8446]).¶
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 [SP800-90c].¶
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, [I-D.ietf-tls-8773bis]).¶
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.¶
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 [I-D.jenkins-cnsa2-pkix-profile].¶
A CNSA TLS client or server MUST NOT include the "early_data" extension.¶
CNSA DTLS clients and servers MUST negotiate DTLS version 1.3, [RFC9147] 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} (Section 4.1 [I-D.ietf-tls-mlkem]).¶
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).¶
Most of the security considerations for this document are described in [RFC8446], [I-D.ietf-tls-8773bis]. Additional security considerations for the use of ML-KEM and ML-DSA in TLS 1.3 can be found in [I-D.ietf-tls-mlkem] and [I-D.ietf-tls-mldsa], respectively.¶
In order to meet the goal of a consistent security level for the entire cipher suite, CNSA TLS implementations MUST use only the algorithms listed in this document. If this is not the case, security may be weaker than is required.¶
As noted in TLS version 1.3 [RFC8446], 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 considerations.¶