



Network Working Group                                          A. Becker
Internet-Draft                                  National Security Agency
Intended status: Informational                            29 August 2025
Expires: 2 March 2026


Commercial National Security Algorithm (CNSA) Suite Profile for TLS 1.3
                   draft-becker-cnsa2-tls-profile-02

Abstract

   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.

Status of This Memo

   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 Notice

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



Becker                    Expires 2 March 2026                  [Page 1]

Internet-Draft              CNSA2 TLS Profile                August 2025


   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.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
   2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   3
   3.  The Commercial National Security Algorithm Suite 2.0  . . . .   4
   4.  CNSA 2.0 Compliance and Interoperability  . . . . . . . . . .   4
     4.1.  CNSA 2.0 Suite  . . . . . . . . . . . . . . . . . . . . .   4
     4.2.  TLS Version . . . . . . . . . . . . . . . . . . . . . . .   5
       4.2.1.  "supported_versions" Extension  . . . . . . . . . . .   5
   5.  Key Exchange Messages . . . . . . . . . . . . . . . . . . . .   5
     5.1.  Cipher Suite Negotiation  . . . . . . . . . . . . . . . .   5
     5.2.  KEM Requirements  . . . . . . . . . . . . . . . . . . . .   6
       5.2.1.  "supported_groups" Extension  . . . . . . . . . . . .   6
       5.2.2.  "key_share" Extension . . . . . . . . . . . . . . . .   6
   6.  Authentication Messages . . . . . . . . . . . . . . . . . . .   7
     6.1.  "signature_algorithms" Extension  . . . . . . . . . . . .   7
     6.2.  "signature_algorithms_cert" Extension . . . . . . . . . .   7
     6.3.  CertificateRequest Message  . . . . . . . . . . . . . . .   8
     6.4.  Certificate Selection . . . . . . . . . . . . . . . . . .   8
     6.5.  CertificateVerify Message . . . . . . . . . . . . . . . .   9
   7.  External Pre-Shared Keys  . . . . . . . . . . . . . . . . . .   9
   8.  Resumption  . . . . . . . . . . . . . . . . . . . . . . . . .  10
   9.  Certificate Status  . . . . . . . . . . . . . . . . . . . . .  10
   10. "early_data" Extension  . . . . . . . . . . . . . . . . . . .  10
   11. DTLS 1.3  . . . . . . . . . . . . . . . . . . . . . . . . . .  10
   12. Security Considerations . . . . . . . . . . . . . . . . . . .  11
   13. IANA Considerations . . . . . . . . . . . . . . . . . . . . .  11
   14. References  . . . . . . . . . . . . . . . . . . . . . . . . .  11
     14.1.  Normative References . . . . . . . . . . . . . . . . . .  11
     14.2.  Informative References . . . . . . . . . . . . . . . . .  13
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .  13











Becker                    Expires 2 March 2026                  [Page 2]

Internet-Draft              CNSA2 TLS Profile                August 2025


1.  Introduction

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

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




Becker                    Expires 2 March 2026                  [Page 3]

Internet-Draft              CNSA2 TLS Profile                August 2025


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

4.  CNSA 2.0 Compliance and Interoperability

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

4.1.  CNSA 2.0 Suite

   CNSA requires the following algorithms for use in TLS 1.3:

   Encryption:





Becker                    Expires 2 March 2026                  [Page 4]

Internet-Draft              CNSA2 TLS Profile                August 2025


      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.

4.2.  TLS Version

   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.

4.2.1.  "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
   [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.

5.  Key Exchange Messages

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

5.1.  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 [RFC8446])

   This CNSA cipher suite MUST be the first (most preferred) cipher
   suite in the ClientHello message and in the extensions.




Becker                    Expires 2 March 2026                  [Page 5]

Internet-Draft              CNSA2 TLS Profile                August 2025


   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.

5.2.  KEM Requirements

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

5.2.1.  "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 [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.

5.2.2.  "key_share" Extension

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






Becker                    Expires 2 March 2026                  [Page 6]

Internet-Draft              CNSA2 TLS Profile                August 2025


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

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

6.1.  "signature_algorithms" Extension

   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.

6.2.  "signature_algorithms_cert" Extension

   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.







Becker                    Expires 2 March 2026                  [Page 7]

Internet-Draft              CNSA2 TLS Profile                August 2025


   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.

6.3.  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} (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.

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



Becker                    Expires 2 March 2026                  [Page 8]

Internet-Draft              CNSA2 TLS Profile                August 2025


   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.

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

7.  External Pre-Shared Keys

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









Becker                    Expires 2 March 2026                  [Page 9]

Internet-Draft              CNSA2 TLS Profile                August 2025


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

9.  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
   [I-D.jenkins-cnsa2-pkix-profile].

10.  "early_data" Extension

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

11.  DTLS 1.3

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








Becker                    Expires 2 March 2026                 [Page 10]

Internet-Draft              CNSA2 TLS Profile                August 2025


12.  Security Considerations

   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.

13.  IANA Considerations

   This document has no IANA considerations.

14.  References

14.1.  Normative References

   [AES]      National Institute of Standards and Technology,
              "Announcing the ADVANCED ENCRYPTION STANDARD (AES)",
              FIPS 197, DOI 10.6028/NIST.FIPS.197, November 2001,
              <https://nvlpubs.nist.gov/nistpubs/fips/
              NIST.FIPS.197.pdf>.

   [cnsafaq]  National Security Agency, "The Commercial National
              Security Algorithm Suite 2.0 and Quantum Computing FAQ",
              December 2024, <https://media.defense.gov/2022/
              Sep/07/2003071836/-1/-1/0/CSI_CNSA_2.0_FAQ_.PDF>.

   [FIPS203]  National Institute of Standards and Technology (2024),
              "Module-Lattice-Based Key-Encapsulation Mechanism
              Standard", (Department of Commerce, Washington,
              D.C.), Federal Information Processing Standards
              Publication (FIPS), NIST FIPS 203,
              <https://doi.org/10.6028/NIST.FIPS.203>.

   [FIPS204]  National Institute of Standards and Technology (2024),
              "Module-Lattice-Based Digital Signature Standard",
              (Department of Commerce, Washington, D.C.), Federal
              Information Processing Standards Publication (FIPS), NIST
              FIPS 204, <https://doi.org/10.6028/NIST.FIPS.204>.




Becker                    Expires 2 March 2026                 [Page 11]

Internet-Draft              CNSA2 TLS Profile                August 2025


   [GCM]      Dworkin, M., "Recommendation for Block Cipher Modes of
              Operation: Galois/Counter Mode (GCM) and GMAC", NIST
              Special Publication 800-38D, DOI 10.6028/NIST.SP.800-38D,
              November 2007,
              <https://nvlpubs.nist.gov/nistpubs/Legacy/SP/
              nistspecialpublication800-38d.pdf>.

   [I-D.ietf-tls-8773bis]
              Housley, R., "TLS 1.3 Extension for Using Certificates
              with an External Pre-Shared Key", July 2024,
              <https://datatracker.ietf.org/doc/draft-ietf-tls-
              8773bis/02/>.

   [I-D.ietf-tls-mldsa]
              Hollebeek, T., Schmieg, S., and B. Westerbaan, "Use of ML-
              DSA in TLS 1.3", May 2025,
              <https://datatracker.ietf.org/doc/draft-ietf-tls-mldsa/>.

   [I-D.ietf-tls-mlkem]
              Connolly, D., "ML-KEM Post-Quantum Key Agreement for TLS
              1.3", April 2025,
              <https://datatracker.ietf.org/doc/draft-ietf-tls-mlkem/>.

   [I-D.jenkins-cnsa2-pkix-profile]
              Jenkins, M. and A. Becker, "Commercial National Security
              Algorithm Suite Certificate and Certificate Revocation
              List Profile", January 2025,
              <https://datatracker.ietf.org/doc/draft-jenkins-cnsa2-
              pkix-profile/>.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <https://www.rfc-editor.org/info/rfc2119>.

   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
              May 2017, <https://www.rfc-editor.org/info/rfc8174>.

   [RFC8446]  Rescorla, E., "The Transport Layer Security (TLS) Protocol
              Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
              <https://www.rfc-editor.org/info/rfc8446>.

   [RFC9147]  Rescorla, E., Tschofenig, H., and N. Modadugu, "The
              Datagram Transport Layer Security (DTLS) Protocol Version
              1.3", RFC 9147, DOI 10.17487/RFC9147, April 2022,
              <https://www.rfc-editor.org/info/rfc9147>.




Becker                    Expires 2 March 2026                 [Page 12]

Internet-Draft              CNSA2 TLS Profile                August 2025


   [SHS]      National Institute of Standards and Technology (NIST),
              "Secure Hash Standard (SHS)", DOI 10.6028/NIST.FIPS.180-4,
              FIPS PUB 180-4, August 2015,
              <https://nvlpubs.nist.gov/nistpubs/FIPS/
              NIST.FIPS.180-4.pdf>.

14.2.  Informative References

   [SP800-90c]
              National Institute of Standards and Technology,
              "Recommendation for Random Bit Generator (RBG)
              Constructions.", NIST SP 800-90C 4pd,
              <https://doi.org/10.6028/NIST.SP.800-90C.4pd>.

   [SP80059]  National Institute of Standards and Technology, "Guideline
              for Identifying an Information System as a National
              Security System", Special Publication 59, DOI
              10.6028/NIST.SP.800-59, August 2003,
              <https://csrc.nist.gov/publications/detail/sp/800-59/
              final>.

Author's Address

   Alison Becker
   National Security Agency
   Email: aebecke@uwe.nsa.gov

























Becker                    Expires 2 March 2026                 [Page 13]
