RFC 9151

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

📅 published April 2022, from ietf

RFC 9151: Commercial National Security Algorithm (CNSA) Suite Profile for TLS and DTLS 1.2 and 1.3 🎀

  • Stream: Independent Submission 💌
  • Author: D. Cooley, NSA 🕵️‍♀️
  • Category: Informational 📚
  • Date: April 2022 📅
  • ISSN: 2070-1721 🔖
  • Obsoletes / Updates: the title block doesn't list anything this RFC obsoletes or updates, so it doesn't replace or change any earlier RFC according to its header 🧐

Abstract 🦋

okay so this doc is a profile, which basically means a set of rules for how to use TLS 1.2 and 1.3 plus DTLS 1.2 and 1.3 with the US Commercial National Security Algorithm (CNSA) Suite. it covers how everything about these protocols is set up, configured, and run for every part of US National Security Systems that uses TLS or DTLS. it's also a good fit for any other US Government system handling high-value information 💅

the profile is published publicly so that developers and operators of these systems (and any other deployments) can use it 🌸

Status of This Memo 📝

this doc is not an Internet Standards Track spec. it's published just for information 💜

it's a contribution to the RFC Series, independent of any other RFC stream. the RFC Editor picked to publish it at their discretion and makes no claims about how useful it is for implementing or deploying anything. docs approved by the RFC Editor aren't candidates for any level of Internet Standard, see Section 2 of RFC 7841 🫶

for the current status, errata, and feedback info, check https://www.rfc-editor.org/info/rfc9151 🔗

Copyright (c) 2022 IETF Trust and the persons identified as the document authors. All rights reserved.

this doc is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) as they stand on the publication date. read those carefully, because they explain your rights and restrictions for this doc ⭐

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 spec is a profile of TLS 1.2 [RFC5246] and TLS 1.3 [RFC8446], plus DTLS 1.2 [RFC6347] and DTLS 1.3 [RFC9147]. it's meant for apps that support the National Security Agency's (NSA) Commercial National Security Algorithm (CNSA) Suite [CNSA]. it applies to the capabilities, configuration, and operation of all components of US National Security Systems [SP80059], and it's also fine for other US Government systems handling high-value info. it's public so developers and operators of these and any other deployments can use it ✨

this doc doesn't define any new cipher suites. instead, it defines a CNSA-compliant profile of TLS and DTLS, using the cipher suites from [RFC5288], [RFC5289], and [RFC8446]. this profile only uses algorithms in the CNSA Suite 🔥

it assumes you already know the TLS 1.2 and 1.3 and DTLS 1.2 and 1.3 protocol specs: [RFC5246], [RFC8446], [RFC6347], and [RFC9147], respectively. every MUST-level requirement from those protocol docs applies all the way through this profile, and they usually aren't repeated here 🫶 this profile also changes some SHOULD-level options up to MUST-level, and some MAY-level options up to SHOULD-level or MUST-level. any option not mentioned here keeps its original requirement level 💅

2. CNSA 🛡️

the National Security Agency (NSA) profiles commercial crypto algorithms and protocols as part of its job of keeping US National Security Systems talking securely and interoperably. to help with the US Government's move to new algorithms, it publishes guidance, and it also gives vendors (and the wider Internet community) info on how to use and configure them properly 📚

the cryptographic transition plans have recently been overshadowed by the possibility of a cryptographically relevant quantum computer. the NSA set up the CNSA Suite to give vendors and IT users near-term flexibility for their Information Assurance (IA) interoperability needs. the whole point of that flexibility is to avoid having vendors and customers go through two major transitions in a short window, since a shift to quantum-resistant cryptography is expected in the near future 🔮

the NSA is writing a set of RFCs, this one included, to give updated guidance on using certain common commercial algorithms in IETF protocols. these RFCs can be used alongside other RFCs and crypto guidance (like NIST Special Publications) to 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 doc are to be read as described in BCP 14 [RFC2119] [RFC8174], but only when they appear in ALL CAPS, like shown here 🔠

"ECDSA" and "ECDH" mean the Elliptic Curve Digital Signature Algorithm (ECDSA) and Elliptic Curve Diffie Hellman (ECDH). both are used with the NIST P-384 curve (based on a 384-bit prime modulus) and the SHA-384 hash function 🌸

"RSA" and "DH" mean Rivest-Shamir-Adleman (RSA) and Finite Field Diffie-Hellman (DH). both are used with a 3072-bit or 4096-bit modulus. when RSA is used for digital signatures, it's paired with the SHA-384 hash function 💜

from here on, this doc refers to TLS 1.2 and 1.3 and DTLS 1.2 and 1.3 together as "(D)TLS" 💖

4. CNSA Suites 💎

[CNSA] approves both the Finite Field and elliptic curve versions of the DH key agreement algorithm, plus RSA-based key establishment. it also approves certain versions of the RSA and elliptic curve digital signature algorithms. the approved encryption includes the Advanced Encryption Standard (AES) with a 256-bit key, used in an Authenticated Encryption with Associated Data (AEAD) mode 🔐

here's what CNSA includes:

  • Encryption:
    • AES [AES] (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 SHA-384 [SHS] as the hash algorithm for mask generation, signature generation, the Pseudorandom Function (PRF) in TLS 1.2, and the HMAC-based Key Derivation Function (HKDF) in TLS 1.3 🌟

4.1. CNSA (D)TLS Key Establishment Algorithms 🗝️

these are the combos of algorithms and key sizes used in CNSA (D)TLS:

  • AES with a 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 a 256-bit key, operating in GCM mode
  • RSA key transport using a 3072-bit or 4096-bit modulus [PWKE-B][RFC8017]
  • TLS PRF/HKDF with SHA-384 [SHS]

or

  • AES with a 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 every case, the client MUST authenticate the server. the server MAY also authenticate the client, if the specific application needs it 🫡

the public keys used to verify these signatures MUST be contained in a certificate (see Section 5.4 for more info) 📜

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. this part is non-negotiable 🙅‍♀️

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 in the CNSA Suite show up in the literature under two different names [DSS] [SECG]. to keep things clear, here are both names:

                 +=======+===========+===========+
                 | Curve | NIST name | SECG name |
                 +=======+===========+===========+
                 | P-384 | nistp384  | secp384r1 |
                 +-------+-----------+-----------+

                    Table 1: Elliptic Curves in
                             CNSA Suite

[RFC8422] defines a bunch 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 💖

Okay so [CNSA] says the minimum modulus size is 3072 bits 🔐, but this profile only supports two sizes: 3072 bits and 4096 bits ✨. Bestie, let's go through the RSA schemes by version!

  • 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:
    • The RSA exponent e MUST satisfy 2^16<e<2^256 and be odd per [DSS]. 🧮
    • If RSASSA-PSS is supported (using rsa_pss_rsae_sha384 for example), 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 [RFC8017] MUST be used, and the salt length MUST be 48 octets. 🌈

5.3. Acceptable Finite Field Groups 🌸

Same deal as before: [CNSA] says 3072 bits is the minimum modulus size 🔐, but this profile only allows 3072 bits and 4096 bits ✨.

Ephemeral key pairs MUST 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:

  • ffdhe3072 (ID=257)
  • ffdhe4096 (ID=258)

5.4. Certificates 📜

Certificates used to establish a CNSA (D)TLS connection are a big deal, so they MUST be signed with ECDSA or RSA and MUST be compliant with the CNSA Suite Certificate and Certificate Revocation List (CRL) Profile [RFC8603]. 🫶

6. (D)TLS 1.2 Requirements 🌸

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 are going to stick around 👀. For the cases where TLS 1.2 continues to be used, implementations MUST use [RFC5246] and SHOULD implement the updates specified in [RFC8446] (outlined in Section 1.3 of that document).

The CNSA (D)TLS 1.2 client MUST offer at least one of these cipher suites:

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 before accepting a non-CNSA-compliant suite. 💅

If interoperability is not desired with non-CNSA-compliant clients or servers, then the session MUST fail if no CNSA Suites are offered or accepted. 💀

6.1. The "extended_master_secret" Extension 🦋

A CNSA (D)TLS client SHOULD include and a CNSA (D)TLS server SHOULD accept the "extended_master_secret" extension as specified in [RFC7627]. See Section 1 of [RFC7627] for security concerns when this extension is not used. 🙈

6.2. The "signature_algorithms" Extension ✨

A CNSA (D)TLS client MUST include and a CNSA (D)TLS server MUST also accept the "signature_algorithms" extension. The CNSA (D)TLS client MUST offer and the CNSA (D)TLS server MUST also accept at least one of the following values in the "signature_algorithms" extensions as specified in [RFC8446]:

  • ecdsa_secp384r1_sha384
  • rsa_pkcs1_sha384

And, if supported, the client SHOULD offer and/or the server SHOULD also accept:

  • rsa_pss_pss_sha384
  • rsa_pss_rsae_sha384

Following the guidance in [RFC8603], CNSA (D)TLS servers MUST only accept ECDSA or RSA for signatures on ServerKeyExchange messages and for certification path validation. 🔒

Other client 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 ServerKeyExchange messages and for certification path validation in non-compliant CNSA (D)TLS connections. These offerings MUST NOT be accepted by a CNSA-compliant (D)TLS server. 🚫

6.3. The "signature_algorithms_cert" Extension 🧚

A CNSA (D)TLS client MAY include the "signature_algorithms_cert" extension. CNSA (D)TLS servers MUST process the "signature_algorithms_cert" extension if it is offered per Section 4.2.3 of [RFC8446]. 🌷

Both CNSA (D)TLS clients and servers MUST use one of the following values for certificate path validation:

  • ecdsa_secp384r1_sha384
  • rsa_pkcs1_sha384

And, if supported, SHOULD offer/accept:

  • rsa_pss_pss_sha384
  • rsa_pss_rsae_sha384

6.4. The CertificateRequest Message 🍓

When a CNSA (D)TLS server is configured to authenticate the client, the server MUST include the following values in its CertificateRequest.supported_signature_algorithms [RFC5246] offer:

  • ecdsa_secp384r1_sha384
  • rsa_pkcs1_sha384

And, if supported as specified in [RFC8446], SHOULD offer/accept:

  • rsa_pss_pss_sha384
  • rsa_pss_rsae_sha384

6.5. The CertificateVerify Message 🔐

A CNSA (D)TLS client MUST use ECDSA or RSA when sending the CertificateVerify message. CNSA (D)TLS servers MUST only accept ECDSA or RSA in the CertificateVerify message. 🥰

6.6. The Signature in the ServerKeyExchange Message ✍️

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

6.7. Certificate Status 🌈

Certificate Authorities (CAs) providing certificates to a CNSA (D)TLS server or client MUST provide certificate revocation status information via a Certificate Revocation List (CRL) distribution point or using the Online Certificate Status Protocol (OCSP). A CNSA client SHOULD request it according to Section 4.4.2.1 of [RFC8446]. If OCSP is supported, the (D)TLS server SHOULD provide OCSP responses in the CertificateStatus message. 📮

7. (D)TLS 1.3 Requirements 🦋

The CNSA (D)TLS client MUST offer the following cipher suite in the ClientHello:

  • TLS_AES_256_GCM_SHA384

The CNSA (D)TLS client MUST include at least one of the following values in the "supported_groups" extension:

  • ECDHE: secp384r1
  • DHE: ffdhe3072
  • DHE: ffdhe4096

The CNSA cipher suite MUST 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 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. 💖

If interoperability is not desired with non-CNSA-compliant clients or servers, then the session MUST fail if no CNSA Suites are offered or accepted. 💀

7.1. The "signature_algorithms" Extension 🫶

A CNSA (D)TLS client MUST include the "signature_algorithms" extension. The CNSA (D)TLS client MUST offer at least one of the following values in the "signature_algorithms" extension:

  • ecdsa_secp384r1_sha384
  • rsa_pss_pss_sha384
  • rsa_pss_rsae_sha384

Clients that allow negotiating TLS 1.2 MAY offer rsa_pkcs1_sha384 for use with TLS 1.2. 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 in non-compliant CNSA (D)TLS connections. These offerings MUST NOT be accepted by a CNSA-compliant (D)TLS server. 🚫

7.2. The "signature_algorithms_cert" Extension 🌸

A CNSA (D)TLS client SHOULD include the "signature_algorithms_cert" extension. And, if offered, the CNSA (D)TLS client MUST offer at least one of the following values in the "signature_algorithms_cert" extension:

  • ecdsa_secp384r1_sha384
  • rsa_pkcs1_sha384

And, if supported, SHOULD offer:

  • rsa_pss_pss_sha384
  • rsa_pss_rsae_sha384

Following the guidance in [RFC8603], CNSA (D)TLS servers MUST only accept ECDSA or RSA for certificate path validation. 🔒

Other offerings MAY be included to indicate the signature algorithms that are acceptable for certification path validation in non-compliant CNSA (D)TLS connections. These offerings MUST NOT be accepted by a CNSA-compliant (D)TLS server. 🙅‍♀️

7.3. The "early_data" Extension 🙈

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

7.4. Resumption 🔁

A CNSA (D)TLS server MAY send a CNSA (D)TLS client a NewSessionTicket message 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 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. 🧚

7.5. Certificate Status 📮

Certificate Authorities (CAs) providing certificates to a CNSA (D)TLS server or client MUST provide certificate revocation status information via a Certificate Revocation List (CRL) distribution point or using the Online Certificate Status Protocol (OCSP). A CNSA client SHOULD request it according to Section 4.4.2.1 of [RFC8446]. If OCSP is supported, the (D)TLS server SHOULD provide OCSP responses in the "CertificateEntry". 🌈

8. Security Considerations ⚠️

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 implementations MUST only use the elliptic curves, RSA schemes, and Finite Fields defined in Section 5.1, Section 5.2, and Section 5.3, respectively. If this is not the case, then security may be weaker than is required.

🚨 This is the big one, bestie: if your implementation mixes in curves, RSA schemes, or finite field groups outside Sections 5.1 through 5.3, the security level can quietly drop below what you actually need. Stay inside the lines. 🚨

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

9. IANA Considerations 🦋

This document has no IANA actions. 🌸

10. References ✨

10.1. Normative References ✨

okay bestie, this is the reference shelf 📚 these are the docs the spec leans on to be legit, so I'm keeping every single one 🫶

10.2. Informative References 🦋

these ones are the extra-helpful reads, not required but so worth a bookmark 🔖

Author's Address 💜

Dorothy Cooley National Security Agency Email: decoole@nsa.gov

📦 where this page comes from