| RFC 9151 | CNSA Suite Profile for (D)TLS | April 2022 |
| Cooley | Informational | [Page] |
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.¶
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 athttps://www.rfc-editor.org/info/rfc9151.¶
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.¶
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. AllMUST-level requirements from the protocol documents apply throughout this profile; they are generally not repeated. This profile contains changes that elevate someSHOULD-level options toMUST-level; this profile also contains changes that elevate someMAY-level options toSHOULD-level orMUST-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 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.¶
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".¶
[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:¶
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.¶
The following combination of algorithms and key sizes are used in CNSA (D)TLS:¶
Or¶
Or¶
The specific CNSA-compliant cipher suites are listed inSection 5.¶
For server and/or client authentication, CNSA (D)TLSMUST generate and verify either ECDSA signatures or RSA signatures.¶
In all cases, the clientMUST authenticate the server. The serverMAY also authenticate the client, as needed by the specific application.¶
The public keys used to verify these signaturesMUST be contained in a certificate (seeSection 5.4 for more information).¶
CNSA (D)TLSMUST NOT use TLS versions prior to (D)TLS 1.2 in a CNSA-compliant system. CNSA (D)TLS servers and clientsMUST implement and use either (D)TLS version 1.2[RFC5246][RFC6347] or (D)TLS version 1.3[RFC8446][RFC9147].¶
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 |
[RFC8422] defines a variety of elliptic curves. CNSA (D)TLS connectionsMUST use secp384r1 (also called nistp384), and the uncompressed formMUST be used, as required by[RFC8422] and[RFC8446].¶
Key pairsMUST be generated following Section 5.6.1.2 of[PWKE-A].¶
[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 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 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.¶
RSA exponent eMUST satisfy 216<e<2256 and be odd per[DSS].¶
If RSASSA-PSS is supported (using rsa_pss_rsae_sha384 for example), then the implementationMUST 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[RFC8017]MUST be used, and the salt lengthMUST be 48 octets.¶
[CNSA] 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 pairsMUST be generated following Section 5.6.1.1.1 of[PWKE-A] using the approved safe prime groups specified in[RFC7919] for DH ephemeral key agreement. The named groups are:¶
Certificates used to establish a CNSA (D)TLS connectionMUST be signed with ECDSA or RSA andMUST be compliant with the CNSA Suite Certificate and Certificate Revocation List (CRL) Profile[RFC8603].¶
Although TLS 1.2 has technically been obsoleted by the IETF in favor of TLS 1.3, many implementations and deployments of TLS 1.2 will continue to exist. For the cases where TLS 1.2 continues to be used, implementationsMUST use[RFC5246] andSHOULD implement the updates specified in[RFC8446] (outlined in Section1.3 of that document).¶
The CNSA (D)TLS 1.2 clientMUST offer at least one of these cipher suites:¶
The CNSA cipher suites listed aboveMUST 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 compliantMAY offer additional cipher suites, but any additional cipher suitesMUST appear after the CNSA cipher suites in the ClientHello message.¶
A CNSA (D)TLS serverMUST accept one of the CNSA Suites above if they are offered in the ClientHello message before accepting a non-CNSA-compliant suite.¶
If interoperability is not desired with non-CNSA-compliant clients or servers, then the sessionMUST fail if no CNSA Suites are offered or accepted.¶
A CNSA (D)TLS clientSHOULD include and a CNSA (D)TLS serverSHOULD accept the "extended_master_secret" extension as specified in[RFC7627]. SeeSection 1 of [RFC7627] for security concerns when this extension is not used.¶
A CNSA (D)TLS clientMUST include and a CNSA (D)TLS serverMUST also accept the "signature_algorithms" extension. The CNSA (D)TLS clientMUST offer and the CNSA (D)TLS serverMUST also accept at least one of the following values in the "signature_algorithms" extensions as specified in[RFC8446]:¶
And, if supported, the clientSHOULD offer and/or the serverSHOULD also accept:¶
Following the guidance in[RFC8603], CNSA (D)TLS serversMUST only accept ECDSA or RSA for signatures on ServerKeyExchange messages and for certification path validation.¶
Other client offeringsMAY 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 ServerKeyExchange messages and for certification path validation in non-compliant CNSA (D)TLS connections. These offeringsMUST NOT be accepted by a CNSA-compliant (D)TLS server.¶
A CNSA (D)TLS clientMAY include the "signature_algorithms_cert" extension. CNSA (D)TLS serversMUST process the "signature_algorithms_cert" extension if it is offered perSection 4.2.3 of [RFC8446].¶
Both CNSA (D)TLS clients and serversMUST use one of the following values for certificate path validation:¶
And, if supported,SHOULD offer/accept:¶
When a CNSA (D)TLS server is configured to authenticate the client, the serverMUST include the following values in its CertificateRequest.supported_signature_algorithms[RFC5246] offer:¶
And, if supported as specified in[RFC8446],SHOULD offer/accept:¶
A CNSA (D)TLS clientMUST use ECDSA or RSA when sending the CertificateVerify message. CNSA (D)TLS serversMUST only accept ECDSA or RSA in the CertificateVerify message.¶
A CNSA (D)TLS serverMUST sign the ServerKeyExchange message using ECDSA or RSA.¶
Certificate Authorities (CAs) providing certificates to a CNSA (D)TLS server or clientMUST provide certificate revocation status information via a Certificate Revocation List (CRL) distribution point or using the Online Certificate Status Protocol (OCSP). A CNSA clientSHOULD request it according toSection 4.4.2.1 of [RFC8446]. If OCSP is supported, the (D)TLS serverSHOULD provide OCSP responses in the CertificateStatus message.¶
The CNSA (D)TLS clientMUST offer the following cipher suite in the ClientHello:¶
The CNSA (D)TLS clientMUST include at least one of the following values in the "supported_groups" extension:¶
The CNSA cipher suiteMUST be the first (most preferred) cipher suite in the ClientHello message and in the extensions.¶
A CNSA (D)TLS client that offers interoperability with servers that are not CNSA compliantMAY offer additional cipher suites, but any additional cipher suitesMUST appear after the CNSA-compliant cipher suites in the ClientHello message.¶
A CNSA (D)TLS serverMUST accept one of the CNSA algorithms listed above if they are offered in the ClientHello message.¶
If interoperability is not desired with non-CNSA-compliant clients or servers, then the sessionMUST fail if no CNSA Suites are offered or accepted.¶
A CNSA (D)TLS clientMUST include the "signature_algorithms" extension. The CNSA (D)TLS clientMUST offer at least one of the following values in the "signature_algorithms" extension:¶
Clients that allow negotiating TLS 1.2MAY offer rsa_pkcs1_sha384 for use with TLS 1.2. Other offeringsMAY be included to indicate the acceptable signature algorithms in cipher suites that are offered for interoperability with servers not compliant with CNSA in non-compliant CNSA (D)TLS connections. These offeringsMUST NOT be accepted by a CNSA-compliant (D)TLS server.¶
A CNSA (D)TLS clientSHOULD include the "signature_algorithms_cert" extension. And, if offered, the CNSA (D)TLS clientMUST offer at least one of the following values in the "signature_algorithms_cert" extension:¶
And, if supported,SHOULD offer:¶
Following the guidance in[RFC8603], CNSA (D)TLS serversMUST only accept ECDSA or RSA for certificate path validation.¶
Other offeringsMAY be included to indicate the signature algorithms that are acceptable for certification path validation in non-compliant CNSA (D)TLS connections. These offeringsMUST NOT be accepted by a CNSA-compliant (D)TLS server.¶
A CNSA (D)TLS client or serverMUST NOT include the "early_data" extension. SeeSection 2.3 of [RFC8446] for security concerns.¶
A CNSA (D)TLS serverMAY send a CNSA (D)TLS client a NewSessionTicket message to enable resumption. A CNSA (D)TLS clientMUST request "psk_dhe_ke" via the "psk_key_exchange_modes" ClientHello extension to resume a session. A CNSA (D)TLS clientMUST offer Ephemeral Elliptic Curve Diffie-Hellman (ECDHE) with SHA-384 and/or Ephemeral Diffie-Hellman (DHE) with SHA-384 in the "supported_groups" and/or "key_share" extensions.¶
Certificate Authorities (CAs) providing certificates to a CNSA (D)TLS server or clientMUST provide certificate revocation status information via a Certificate Revocation List (CRL) distribution point or using the Online Certificate Status Protocol (OCSP). A CNSA clientSHOULD request it according toSection 4.4.2.1 of [RFC8446]. If OCSP is supported, the (D)TLS serverSHOULD provide OCSP responses in the "CertificateEntry".¶
Most of the security considerations for this document are described in[RFC5246],[RFC8446],[RFC6347], and[RFC9147]. In addition, the security considerations for Elliptic Curve Cryptography (ECC) related to TLS are described in[RFC8422],[RFC5288], and[RFC5289]. Readers should consult those documents.¶
In order to meet the goal of a consistent security level for the entire cipher suite, CNSA (D)TLS implementationsMUST only use the elliptic curves, RSA schemes, and Finite Fields defined inSection 5.1,Section 5.2, andSection 5.3, respectively. If this is not the case, then 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 actions.¶