rfc9151xml2.original.xml   rfc9151.xml 
<?xml version="1.0" encoding="UTF-8"?> <?xml version="1.0" encoding="UTF-8"?>
<!-- ===== CONTEXT SETTINGS ===== --> <!DOCTYPE rfc SYSTEM "rfc2629-xhtml.ent">
<!-- Create an entry here for every RFC referenced. -->
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY rfc2119 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC
.2119.xml">
<!ENTITY rfc5246 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC
.5246.xml">
<!ENTITY rfc5288 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC
.5288.xml">
<!ENTITY rfc5289 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC
.5289.xml">
<!ENTITY rfc6347 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC
.6347.xml">
<!ENTITY rfc7627 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC
.7627.xml">
<!ENTITY rfc7919 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC
.7919.xml">
<!ENTITY rfc8017 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC
.8017.xml">
<!ENTITY rfc8174 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC
.8174.xml">
<!ENTITY rfc8422 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC
.8422.xml">
<!ENTITY rfc8446 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC
.8446.xml">
<!ENTITY rfc8603 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC
.8603.xml">
]>
<!-- Extra statement used by XSLT processors to control the output style. -->
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<!-- Fill in file name. -->
<rfc category="info" ipr="trust200902" docName="draft-cooley-cnsa-dtls-tls-profi
le-07" >
<!-- Processing Instructions - these should cover most cases-->
<?rfc strict="yes" ?>
<?rfc comments="no" ?>
<?rfc inline="no" ?>
<?rfc editing="no" ?>
<!-- Table of Contents (ToC) and options -->
<?rfc toc="yes"?> <!-- idnits insists on a ToC if the document has more
than 15 pages -->
<?rfc tocompact="yes"?> <!-- yes - eliminate blank lines before main section
entries -->
<?rfc tocdepth="2"?> <!-- Sets the number of levels of sections/subsection
s in ToC -->
<!-- Choose options for the references. The tags used are the anchor attribu
tes of the references. -->
<?rfc symrefs="yes"?> <!-- yes - use symbolic references in xref tags -
->
<?rfc sortrefs="yes" ?> <!-- yes - If symrefs also yes, sort references i
n order of tags. -->
<?rfc compact="yes" ?> <!-- yes - don't start each main section on a new
page -->
<?rfc subcompact="no" ?> <!-- yes - also omit blank lines between list ite
ms -->
<!-- end Processing Instructions -->
<!-- ===== END CONTEXT SETTINGS ===== -->
<front> <!-- ===== FRONT MATTER ===== --> <rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft
-cooley-cnsa-dtls-tls-profile-07" number="9151" obsoletes="" updates="" submissi
onType="independent" category="info" xml:lang="en" tocInclude="true" tocDepth="2
"
symRefs="true" sortRefs="true" version="3">
<title abbrev="CNSA Suite TLS Profile">Commercial National Security Algorith m (CNSA) Suite Profile for TLS and DTLS 1.2 and 1.3</title> <front>
<title abbrev="CNSA Suite Profile for (D)TLS">Commercial National Security A
lgorithm (CNSA) Suite Profile for TLS and DTLS 1.2 and 1.3</title>
<seriesInfo name="RFC" value="9151"/>
<author fullname="Dorothy Cooley" initials="D." surname="Cooley"> <author fullname="Dorothy Cooley" initials="D." surname="Cooley">
<organization abbrev="NSA">National Security Agency</organization> <organization abbrev="NSA">National Security Agency</organization>
<address><email>decoole@nsa.gov</email></address> <address>
<email>decoole@nsa.gov</email>
</address>
</author> </author>
<date year="2021" month="August" />
<date year="2021"/> <!-- Current month and day will be filled in. -->
<!-- Meta-data Declarations -->
<area>Security</area> <area>Security</area>
<workgroup>Network Working Group</workgroup> <workgroup>Network Working Group</workgroup>
<!-- There must be an abstract. -->
<abstract> <abstract>
<t>This document defines a base profile for TLS protocol versions 1.2
<t>This document defines a base profile for TLS protocol versions 1.2 and 1.3, a and 1.3 as well as DTLS protocol versions 1.2 and 1.3 for use with the
s well as DTLS protocol versions 1.2 and 1.3 for use with the United States Comm US Commercial National Security Algorithm (CNSA) Suite.
ercial National Security Algorithm (CNSA) Suite. </t>
</t> <t>The profile applies to the capabilities, configuration, and operation
of all components of US National Security Systems that use TLS or DTLS.
<t>The profile applies to the capabilities, configuration, and operation of all It is also appropriate for all other US Government systems that process
components of US National Security Systems that use TLS or DTLS. It is also app high-value information.
ropriate for all other US Government systems that process high-value information
.
</t> </t>
<t>The profile is made publicly available here for use by developers and
<t>The profile is made publicly available here for use by developers and operato operators of these and any other system deployments.
rs of these and any other system deployments.
</t> </t>
</abstract> </abstract>
</front>
</front> <!-- ===== END FRONT MATTER ===== --> <middle>
<middle> <!-- ===== DOCUMENT BODY ===== -->
<section anchor="intro" title="Introduction">
<t>This document specifies a profile of TLS version 1.2 <xref target="RFC5246" / <section anchor="intro" numbered="true" toc="default">
> and TLS version 1.3 <xref target="RFC8446" />, as well as DTLS version 1.2 <xr <name>Introduction</name>
ef target="RFC6347"/> and DTLS version 1.3 <xref target="ID.dtls13" /> for use b <t>This document specifies a profile of TLS version 1.2 <xref target="RFC5
y applications that support the National Security Agency's (NSA) Commercial Nati 246" format="default"/> and TLS version 1.3 <xref target="RFC8446" format="defau
onal Security Algorithm (CNSA) Suite <xref target="CNSA" />. The profile applie lt"/> as well as DTLS version 1.2 <xref target="RFC6347" format="default"/> and
s to the capabilities, configuration, and operation of all components of US Nati DTLS version 1.3 <xref target="RFC9147" format="default"/> for use by applicatio
onal Security Systems <xref target="SP80059" />. It is also appropriate for all ns that support the National Security Agency's (NSA) Commercial National Securit
other US Government systems that process high-value information. It is made publ y Algorithm (CNSA) Suite <xref target="CNSA" format="default"/>. The profile ap
icly available for use by developers and operators of these and any other system plies to the capabilities, configuration, and operation of all components of US
deployments. National Security Systems <xref target="SP80059" format="default"/>. It is also
appropriate for all other US Government systems that process high-value informat
ion. It is made publicly available for use by developers and operators of these
and any other system deployments.
</t> </t>
<t>This document does not define any new cipher suites; instead, it define
<t>This document does not define any new cipher suites; instead, it defines a CN s a CNSA-compliant profile of TLS and DTLS, and the cipher suites defined in <xr
SA compliant profile of TLS and DTLS, and the cipher suites defined in <xref tar ef target="RFC5288" format="default"/>, <xref target="RFC5289" format="default"/
get="RFC5288" />, <xref target="RFC5289" />, and <xref target="RFC8446" />. Thi >, and <xref target="RFC8446" format="default"/>. This profile uses only algori
s profile uses only algorithms in the CNSA Suite. thms in the CNSA Suite.
</t> </t>
<t>The reader is assumed to have familiarity with the TLS 1.2 and 1.3 as w
<t>The reader is assumed to have familiarity with the TLS 1.2 and 1.3 as well as ell as the DTLS 1.2 and 1.3 protocol specifications: <xref target="RFC5246" form
the DTLS 1.2 and 1.3 protocol specifications: <xref target="RFC5246" />, <xref at="default"/>, <xref target="RFC8446" format="default"/>, <xref target="RFC634
target="RFC6347"/>, <xref target="RFC8446" />, and <xref target="ID.dtls13" />. 7" format="default"/>, and <xref target="RFC9147" format="default"/>, respective
All MUST-level requirements from the protocol documents apply throughout this p ly. All <bcp14>MUST</bcp14>-level requirements from the protocol documents appl
rofile; they are generally not repeated. This profile contains changes that ele y throughout this profile; they are generally not repeated. This profile contai
vate some SHOULD-level options to MUST-level; this profile also contains changes ns changes that elevate some <bcp14>SHOULD</bcp14>-level options to <bcp14>MUST<
that elevate some MAY-level options to SHOULD-level or MUST-level. All options /bcp14>-level; this profile also contains changes that elevate some <bcp14>MAY</
that are not mentioned in this profile remain at their original requirement lev bcp14>-level options to <bcp14>SHOULD</bcp14>-level or <bcp14>MUST</bcp14>-level
el. . All options that are not mentioned in this profile remain at their original r
equirement level.
</t> </t>
</section>
</section> <!-- intro --> <section anchor="cnsa" numbered="true" toc="default">
<name>CNSA</name>
<section anchor="cnsa" title="The Commercial National Security Algorithm Suite"> <t>The National Security Agency (NSA) profiles commercial cryptographic
algorithms and protocols as part of its mission to support secure,
<t>The National Security Agency (NSA) profiles commercial cryptographic algorith interoperable communications for US National Security Systems. To this
ms and protocols as part of its mission to support secure, interoperable communi end, it publishes guidance both to assist with the US Government
cations for US Government National Security Systems. To this end, it publishes g transition to new algorithms and to provide vendors -- and the Internet
uidance both to assist with the US Government transition to new algorithms, and community in general -- with information concerning their proper use and
to provide vendors - and the Internet community in general - with information co configuration.
ncerning their proper use and configuration.
</t> </t>
<t>Recently, cryptographic transition plans have become overshadowed by th
<t>Recently, cryptographic transition plans have become overshadowed by the pros e prospect of the development of a cryptographically relevant quantum computer.
pect of the development of a cryptographically-relevant quantum computer. NSA h The NSA has established the CNSA Suite to provide vendors and IT users near-ter
as established the CNSA Suite to provide vendors and IT users near-term flexibil m flexibility in meeting their Information Assurance (IA) interoperability requi
ity in meeting their Information Assurance (IA) interoperability requirements. T rements. The purpose behind this flexibility is to avoid having vendors and cust
he purpose behind this flexibility is to avoid having vendors and customers make omers make two major transitions in a relatively short timeframe, as we anticipa
two major transitions in a relatively short timeframe, as we anticipate a need te a need to shift to quantum-resistant cryptography in the near future.
to shift to quantum-resistant cryptography in the near future.
</t> </t>
<t>The NSA is authoring a set of RFCs, including this one, to provide
<t>NSA is authoring a set of RFCs, including this one, to provide updated guidan updated guidance concerning the use of certain commonly available
ce concerning the use of certain commonly available commercial algorithms in IET commercial algorithms in IETF protocols. These RFCs can be used in
F protocols. These RFCs can be used in conjunction with other RFCs and cryptogr conjunction with other RFCs and cryptographic guidance (e.g., NIST
aphic guidance (e.g., NIST Special Publications) to properly protect Internet tr Special Publications) to properly protect Internet traffic and
affic and data-at-rest for US Government National Security Systems. data-at-rest for US National Security Systems.
</t> </t>
</section>
</section> <!-- cnsa --> <section anchor="terms" numbered="true" toc="default">
<name>Terminology</name>
<section anchor="terms" title="Terminology"> <t>The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14
>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL NOT</bcp14>", "<bcp14>
<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>RECOMMENDED</bcp14>", "<bc
"SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this d p14>NOT RECOMMENDED</bcp14>", "<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>
ocument are to be interpreted as described in BCP 14 <xref target="RFC2119" /> < " in this document are to be interpreted as described in BCP&nbsp;14 <xref targe
xref target="RFC8174" /> when, and only when, they appear in all capitals, as sh t="RFC2119" format="default"/> <xref target="RFC8174" format="default"/> when, a
own here. nd only when, they appear in all capitals, as shown here.
</t> </t>
<t>"ECDSA" and "ECDH" refer to the use of the Elliptic Curve Digital Signature A lgorithm (ECDSA) and Elliptic Curve Diffie Hellman (ECDH), respectively. ECDSA a nd ECDH are used with the NIST P-384 curve (which is based on a 384-bit prime mo dulus) and the SHA-384 hash function. Similarly, "RSA" and "DH" refer to Rivest -Shamir-Adleman (RSA) and Finite Field Diffie-Hellman (DH), respectively. RSA an d 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. <t>"ECDSA" and "ECDH" refer to the use of the Elliptic Curve Digital Signa ture Algorithm (ECDSA) and Elliptic Curve Diffie Hellman (ECDH), respectively. E CDSA and ECDH are used with the NIST P-384 curve (which is based on a 384-bit pr ime 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 d igital signature, it is used with the SHA-384 hash function.
</t> </t>
<t>Henceforth, this document refers to TLS versions 1.2 and 1.3 and DTLS v
<t>Henceforth, this document refers to TLS versions 1.2 and 1.3 and DTLS version ersions 1.2 and 1.3 collectively as "(D)TLS".
s 1.2 and 1.3 collectively as (D)TLS.
</t> </t>
</section>
</section> <!-- terms --> <section anchor="cnsa-suite" numbered="true" toc="default">
<name>CNSA Suites</name>
<section anchor="cnsa-suite" title="CNSA Suite"> <t><xref target="CNSA" format="default"/> approves the use of both Finite
Field and elliptic curve versions of the DH key agreement algorithm as well as R
<t><xref target="CNSA" /> approves the use of both finite field and elliptic cur SA-based key establishment. <xref target="CNSA" format="default"/> also approves
ve versions of the DH key agreement algorithm, as well as RSA-based key establis certain versions of the RSA and elliptic curve digital signature algorithms. Th
hment. <xref target="CNSA" /> also approves certain versions of the RSA and elli e approved encryption techniques include the Advanced Encryption Standard (AES)
ptic curve digital signature algorithms. The approved encryption techniques incl used with a 256-bit key in an Authenticated Encryption with Associated Data (AEA
ude the Advanced Encryption Standard (AES) used with a 256-bit key in an Authent D) mode.
icated Encryption with Associated Data (AEAD) mode.
</t> </t>
<t>In particular, CNSA includes the following:
<t>In particular, CNSA includes the following:
<list style="empty">
<t>Encryption:
<list style="empty">
<t>AES <xref target="AES" /> (with key size 256 bits), operating in Galois/C
ounter Mode (GCM) <xref target="GCM" /></t>
</list>
</t>
<t>Digital Signature:
<list style="empty">
<t>ECDSA <xref target="DSS" /> (using the NIST P-384 elliptic curve)</t>
<t>RSA <xref target="DSS" /> (with a modulus of 3072 bits or 4096 bits)</t>
</list>
</t>
<t>Key Establishment (includes key agreement and key transport):
<list style="empty">
<t>ECDH <xref target="PWKE-A" /> (using the NIST P-384 elliptic curve)</t>
<t>DH <xref target="PWKE-A" /> (with a prime modulus of 3072 or 4096 bits)</
t>
<t>RSA <xref target="PWKE-B" /> (with a modulus of 3072 or 4096 bits, but on
ly in (D)TLS 1.2)</t>
</list>
</t>
</list>
</t> </t>
<t><xref target="CNSA" /> also approves the use of SHA-384 <xref target="SHS" /> <dl newline="true">
for the hash algorithm for mask generation, signature generation, Pseudo Random
Function (PRF) in TLS 1.2 and HMAC-based key derivation function (HKDF) in TLS
1.3.
</t>
<section anchor="tls-ke" title="CNSA (D)TLS Key Establishment Algorithms"> <dt>Encryption:
</dt>
<dd>AES <xref target="AES" format="default"/> (with key size 256 bits),
operating in Galois/Counter Mode (GCM) <xref target="GCM" format="default"/>
</dd>
<t>The following combination of algorithms and key sizes are used in CNSA (D)TLS <dt>Digital Signature:
: </dt>
<dd><t>ECDSA <xref target="DSS" format="default"/> (using the NIST P-384
elliptic curve)</t>
<t>RSA <xref target="DSS" format="default"/> (with a modulus of
3072 bits or 4096 bits)</t>
<list style="empty"> </dd>
<t>AES with 256-bit key, operating in GCM mode</t>
<t>ECDH <xref target="PWKE-A" /> using the Ephemeral Unified Model Scheme with
cofactor set to 1 (see Section 6.1.2.2 in <xref target="PWKE-A" />)</t>
<t>TLS PRF/HKDF with SHA-384 <xref target="SHS" /></t>
</list>
</t>
<t>Or <dt>Key Establishment (includes key agreement and key transport):
</dt>
<dd>
<t>ECDH <xref target="PWKE-A" format="default"/> (using the NIST P-384
elliptic curve)</t>
<t>DH <xref target="PWKE-A" format="default"/> (with a prime
modulus of 3072 or 4096 bits)</t>
<t>RSA <xref target="PWKE-B" format="default"/> (with a modulus of
3072 or 4096 bits, but only in (D)TLS 1.2)</t>
</dd>
<list style="empty"> </dl>
<t>AES with 256-bit key, operating in GCM mode</t>
<t>RSA key transport using 3072-bit or 4096-bit modulus <xref target="PWKE-B" <t><xref target="CNSA" format="default"/> also approves the use of SHA-384 <xref
/><xref target="RFC8017" /></t> target="SHS" format="default"/> as the hash algorithm for mask generation, sign
<t>TLS PRF/HKDF with SHA-384 <xref target="SHS" /></t> ature generation, Pseudorandom Function (PRF) in TLS 1.2 and HMAC-based Key Deri
</list> vation Function (HKDF) in TLS 1.3.
</t> </t>
<t>Or <section anchor="tls-ke" numbered="true" toc="default">
<name>CNSA (D)TLS Key Establishment Algorithms</name>
<t>The following combination of algorithms and key sizes are used in CNS
A (D)TLS:
<list style="empty">
<t>AES with 256-bit key, operating in GCM mode</t>
<t>DH using dhEphem with domain parameters specified below in <xref target="ff
-groups"/> (see Section 6.1.2.1 in <xref target="PWKE-A" />)</t>
<t>TLS PRF/HKDF with SHA-384 <xref target="SHS" /></t>
</list>
</t> </t>
<ul empty="true" spacing="normal">
<li>AES with 256-bit key, operating in GCM mode</li>
<li>ECDH <xref target="PWKE-A" format="default"/> using the
Ephemeral Unified Model Scheme with cofactor set to 1 (see Section
6.1.2.2 in <xref target="PWKE-A" format="default"/>)</li>
<li>TLS PRF/HKDF with SHA-384 <xref target="SHS" format="default"/></l
i>
</ul>
<t>Or
<t>The specific CNSA compliant cipher suites are listed in Section 5.
</t> </t>
<ul empty="true" spacing="normal">
<li>AES with 256-bit key, operating in GCM mode</li>
<li>RSA key transport using 3072-bit or 4096-bit modulus <xref target=
"PWKE-B" format="default"/><xref target="RFC8017" format="default"/></li>
<li>TLS PRF/HKDF with SHA-384 <xref target="SHS" format="default"/></l
i>
</ul>
<t>Or
</section> <!-- tls-ke -->
<section anchor="tls-auth" title="CNSA TLS Authentication">
<t>For server and/or client authentication, CNSA (D)TLS MUST generate and verify
either ECDSA signatures or RSA signatures.
</t> </t>
<ul empty="true" spacing="normal">
<t>In all cases, the client MUST authenticate the server. The server MAY also a <li>AES with 256-bit key, operating in GCM mode</li>
uthenticate the client, as needed by the specific application. <li>DH using dhEphem with domain parameters specified below in <xref t
arget="ff-groups" format="default"/> (see Section 6.1.2.1 in <xref target="PWKE-
A" format="default"/>)</li>
<li>TLS PRF/HKDF with SHA-384 <xref target="SHS" format="default"/></l
i>
</ul>
<t>The specific CNSA-compliant cipher suites are listed in <xref target=
"compliance"/>.
</t> </t>
</section>
<t>The public keys used to verify these signatures MUST be contained in a certif <section anchor="tls-auth" numbered="true" toc="default">
icate, see Section 5.4 for more information.</t> <name>CNSA TLS Authentication</name>
<t>For server and/or client authentication, CNSA (D)TLS <bcp14>MUST</bcp
</section> <!-- tls-auth --> 14> generate and verify either ECDSA signatures or RSA signatures.
</section> <!-- cnsa-suite -->
<section anchor="compliance" title="CNSA Compliance and Interoperability Require
ments">
<t>CNSA (D)TLS MUST NOT use TLS versions prior to (D)TLS 1.2 in a CNSA compliant
system. CNSA (D)TLS servers and clients MUST implement and use either (D)TLS v
ersion 1.2 <xref target="RFC5246" /><xref target="RFC6347" /> or (D)TLS version
1.3 <xref target="RFC8446" /><xref target="ID.dtls13" />.
</t> </t>
<t>In all cases, the client <bcp14>MUST</bcp14> authenticate the
<section anchor="ecc-curves" title="Acceptable ECC Curves"> server. The server <bcp14>MAY</bcp14> also authenticate the client, as
needed by the specific application.
<t>The elliptic curves used in the CNSA Suite appear in the literature under two
different names <xref target="DSS" /> <xref target="SECG" />. For the sake of
clarity, both names are listed below:
</t> </t>
<t>The public keys used to verify these signatures <bcp14>MUST</bcp14>
be contained in a certificate (see <xref target="certs"/> for more
information).</t>
</section>
<figure><artwork align="left"> </section>
Curve NIST name SECG name
--------------------------------
P-384 nistp384 secp384r1
</artwork></figure>
<t><xref target="RFC8422" /> defines a variety of elliptic curves. CNSA (D)TLS <section anchor="compliance" numbered="true" toc="default">
connections MUST use secp384r1 (also called nistp384) and the uncompressed form <name>CNSA Compliance and Interoperability Requirements</name>
MUST be used, as required by <xref target="RFC8422" /> and <xref target="RFC8446 <t>CNSA (D)TLS <bcp14>MUST NOT</bcp14> use TLS versions prior to (D)TLS
" />. 1.2 in a CNSA-compliant system. CNSA (D)TLS servers and clients
<bcp14>MUST</bcp14> implement and use either (D)TLS version 1.2 <xref
target="RFC5246" format="default"/> <xref target="RFC6347"
format="default"/> or (D)TLS version 1.3 <xref target="RFC8446"
format="default"/> <xref target="RFC9147" format="default"/>.
</t> </t>
<section anchor="ecc-curves" numbered="true" toc="default">
<t>Key pairs MUST be generated following Section 5.6.1.2 of <xref target="PWKE-A <name>Acceptable Elliptic Curve Cryptography (ECC) Curves</name>
" />. <t>The elliptic curves used in the CNSA Suite appear in the literature
under two different names <xref target="DSS" format="default"/> <xref
target="SECG" format="default"/>. For the sake of clarity, both names
are listed below:
</t> </t>
</section> <!-- ecc-curves --> <table anchor="elliptic_curve_table">
<name>Elliptic Curves in CNSA Suite</name>
<thead>
<tr>
<th>Curve</th>
<th>NIST name</th>
<th>SECG name</th>
</tr>
</thead>
<tbody>
<tr>
<td>P-384</td>
<td>nistp384</td>
<td>secp384r1</td>
</tr>
<section anchor="rsa-schemes" title="Acceptable RSA Schemes, Parameters and Chec </tbody>
ks"> </table>
<t><xref target="CNSA" /> specifies a minimum modulus size of 3072 bits; however , only two modulus sizes (3072 bits and 4096 bits) are supported by this profile . <t><xref target="RFC8422" format="default"/> defines a variety of ellipt ic curves. CNSA (D)TLS connections <bcp14>MUST</bcp14> use secp384r1 (also call ed nistp384), and the uncompressed form <bcp14>MUST</bcp14> be used, as required by <xref target="RFC8422" format="default"/> and <xref target="RFC8446" format= "default"/>.
</t> </t>
<t>Key pairs <bcp14>MUST</bcp14> be generated following Section 5.6.1.2
<t> of <xref target="PWKE-A" format="default"/>.
<list style="empty">
<t>For (D)TLS 1.2:</t>
<t>
<list style="empty">
<t>For certificate signature, RSASSA-PKCS1-v1.5 <xref target="RFC8017" /> MU
ST be supported, and RSASSA-PSS <xref target="DSS" /> SHOULD be supported.</t>
<t>For signatures in TLS handshake messages RSASSA-PKCS1-v1.5 <xref target="
RFC8017" /> MUST be supported, and RSASSA-PSS <xref target="DSS" /> SHOULD be su
pported.</t>
<t>For key transport, RSAES-PKCS1-v1.5 <xref target="RFC8017" /> MUST be sup
ported.</t>
</list>
</t>
<t>For (D)TLS 1.3:</t>
<t>
<list style="empty">
<t>For certificate signature, RSASSA-PKCS1-v1.5 <xref target="RFC8017" /> MU
ST be supported, and RSASSA-PSS <xref target="DSS" /> SHOULD be supported.</t>
<t>For signatures in TLS handshake messages RSASSA-PSS <xref target="DSS" />
MUST be supported.</t>
<t>For key transport, TLS 1.3 does not support RSA key transport.</t>
</list>
</t>
<t>For all versions of (D)TLS:</t>
<t>
<list style="empty">
<t>RSA exponent e MUST satisfy 2^16&lt;e&lt;2^256 and be odd per <xref targe
t="DSS" />.</t>
<t>If RSASSA-PSS is supported (using rsa_pss_rsae_sha384 for example), then
the implementation MUST assert rsaEncryption as the public key algorithm, the ha
sh algorithm (used for both mask generation and signature generation) MUST be SH
A-384, the mask generation function 1 (MGF1) from <xref target="RFC8017" /> MUST
be used, and the salt length MUST be 48 octets.</t>
</list>
</t>
</list>
</t> </t>
</section>
</section> <!-- rsa-schemes --> <section anchor="rsa-schemes" numbered="true" toc="default">
<name>Acceptable RSA Schemes, Parameters, and Checks</name>
<section anchor="ff-groups" title="Acceptable Finite Field Groups"> <t><xref target="CNSA" format="default"/> specifies a minimum modulus si
ze of 3072 bits; however, only two modulus sizes (3072 bits and 4096 bits) are s
<t><xref target="CNSA" /> specifies a minimum modulus size of 3072 bits; however upported by this profile.
, only two modulus sizes (3072 bits and 4096 bits) are supported by this profile
.
</t> </t>
<t>Ephemeral key pairs MUST be generated following Section 5.6.1.1.1 of <xref ta rget="PWKE-A" /> using the approved safe prime groups specified in <xref target= "RFC7919" /> for DH ephemeral key agreement. The named groups are: <dl newline="true">
<list style="empty"> <dt>For (D)TLS 1.2:
<t>ffdhe3072 (ID=257)</t> </dt>
<t>ffdhe4096 (ID=258)</t> <dd><t>For certificate signatures, RSASSA-PKCS1-v1_5 <xref target="RFC8017"
</list> format="default"/> <bcp14>MUST</bcp14> be supported, and RSASSA-PSS <xref target
</t> ="DSS"
format="default"/> <bcp14>SHOULD</bcp14> be supported.</t>
</section> <!-- ff-groups --> <t>For signatures in TLS handshake messages, RSASSA-PKCS1-v1_5 <xr
ef
target="RFC8017" format="default"/> <bcp14>MUST</bcp14> be supported, and RSASSA
-PSS <xref
target="DSS" format="default"/> <bcp14>SHOULD</bcp14> be supported.</t>
<t>For key transport, RSAES-PKCS1-v1_5 <xref target="RFC8017"
format="default"/> <bcp14>MUST</bcp14> be supported.</t>
</dd>
<section anchor="certs" title="Certificates"> <dt>For (D)TLS 1.3:
</dt>
<dd><t>For certificate signatures, RSASSA-PKCS1-v1_5 <xref target="RFC8017"
format="default"/> <bcp14>MUST</bcp14> be supported, and RSASSA-PSS <xref
target="DSS" format="default"/> <bcp14>SHOULD</bcp14> be supported.</t>
<t>For signatures in TLS handshake messages, RSASSA-PSS <xref
target="DSS" format="default"/> <bcp14>MUST</bcp14> be
supported.</t>
<t>For key transport, TLS 1.3 does not support RSA key
transport.</t>
</dd>
<t>Certificates used to establish a CNSA (D)TLS connection MUST be signed with E <dt>For all versions of (D)TLS:
CDSA or RSA and MUST be compliant with the "CNSA Certificate and Certificate Rev </dt>
ocation List (CRL) Profile" <xref target="RFC8603" />.
</t>
</section> <!-- certs --> <dd>
<t>RSA exponent e <bcp14>MUST</bcp14> satisfy
2<sup>16</sup>&lt;e&lt;2<sup>256</sup> and be odd per <xref target="DSS"
format="default"/>.</t>
<t>If RSASSA-PSS is supported (using rsa_pss_rsae_sha384 for example), then
the implementation <bcp14>MUST</bcp14> assert rsaEncryption as the public
key algorithm, the hash algorithm (used for both mask generation and
signature generation) <bcp14>MUST</bcp14> be SHA-384, the mask generation
function 1 (MGF1) from <xref target="RFC8017" format="default"/>
<bcp14>MUST</bcp14> be used, and the salt length <bcp14>MUST</bcp14> be 48
octets.</t>
</dd>
</section> <!-- compliance --> </dl>
<section anchor="tls12-reqts" title="(D)TLS 1.2 Requirements"> </section>
<t>Although TLS 1.2 has technically been obsoleted by the IETF in favor of TLS 1 <section anchor="ff-groups" numbered="true" toc="default">
.3, many implementations and deployments of TLS 1.2 will continue to exist. For <name>Acceptable Finite Field Groups</name>
the cases where TLS 1.2 continues to be used, implementations MUST use <xref ta <t><xref target="CNSA" format="default"/> specifies a minimum modulus si
rget="RFC5246" /> and SHOULD implement the updates specified in <xref target="RF ze of 3072 bits; however, only two modulus sizes (3072 bits and 4096 bits) are s
C8446" /> (outlined in Section 1.3). upported by this profile.
</t> </t>
<t>Ephemeral key pairs <bcp14>MUST</bcp14> be generated following Sectio n 5.6.1.1.1 of <xref target="PWKE-A" format="default"/> using the approved safe prime groups specified in <xref target="RFC7919" format="default"/> for DH ephem eral key agreement. The named groups are:
<t>The CNSA (D)TLS 1.2 client MUST offer at least one of these ciphersuites:
<list style="empty">
<t>TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 <xref target="RFC5289" /> <xref tar
get="RFC8422" /></t>
<t>TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 <xref target="RFC5289" /> <xref targe
t="RFC8422" /></t>
<t>TLS_RSA_WITH_AES_256_GCM_SHA384 <xref target="RFC5288" /></t>
<t>TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 <xref target="RFC5288" /> <xref target=
"RFC7919" /></t>
</list>
</t> </t>
<ul empty="true" spacing="normal">
<li>ffdhe3072 (ID=257)</li>
<li>ffdhe4096 (ID=258)</li>
</ul>
</section>
<t>The CNSA cipher suites listed above MUST be the first (most preferred) cipher <section anchor="certs" numbered="true" toc="default">
suites in the ClientHello message. <name>Certificates</name>
<t>Certificates used to establish a CNSA (D)TLS connection <bcp14>MUST</
bcp14> be signed with ECDSA or RSA and <bcp14>MUST</bcp14> be compliant with the
CNSA Suite Certificate and Certificate Revocation List (CRL) Profile <xref targ
et="RFC8603" format="default"/>.
</t> </t>
</section>
<t>A CNSA (D)TLS client that offers interoperability with servers that are not C </section>
NSA compliant MAY offer additional cipher suites, but any additional cipher suit
es MUST appear after the CNSA cipher suites in the ClientHello message.
</t>
<t>A CNSA (D)TLS server MUST accept one of the CNSA suites above if they are off <section anchor="tls12-reqts" numbered="true" toc="default">
ered in the ClientHello message before accepting a non-CNSA compliant suite. <name>(D)TLS 1.2 Requirements</name>
<t>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, implementations <bcp14>MUST
</bcp14> use <xref target="RFC5246" format="default"/> and <bcp14>SHOULD</bcp14>
implement the updates specified in <xref target="RFC8446" format="default"/> (o
utlined in Section <xref sectionFormat="bare" section="1.3" target="RFC8446"/> o
f that document).
</t> </t>
<t>The CNSA (D)TLS 1.2 client <bcp14>MUST</bcp14> offer at least one of th ese cipher suites:
<t>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.
</t> </t>
<ul empty="true" spacing="normal">
<section anchor="ext-master-secret" title="The extended_master_secret Extension" <li>TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 <xref target="RFC5289" forma
> t="default"/> <xref target="RFC8422" format="default"/></li>
<li>TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 <xref target="RFC5289" format=
<t>A CNSA (D)TLS client SHOULD include and a CNSA (D)TLS server SHOULD accept th "default"/> <xref target="RFC8422" format="default"/></li>
e "extended_master_secret" extension as specified in <xref target="RFC7627" />. <li>TLS_RSA_WITH_AES_256_GCM_SHA384 <xref target="RFC5288" format="defau
See Section 1 of <xref target="RFC7627" /> for security concerns when this exten lt"/></li>
sion is not used. <li>TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 <xref target="RFC5288" format="d
efault"/> <xref target="RFC7919" format="default"/></li>
</ul>
<t>The CNSA cipher suites listed above <bcp14>MUST</bcp14> be the first
(most preferred) cipher suites in the ClientHello message.
</t> </t>
<t>A CNSA (D)TLS client that offers interoperability with servers that are
</section> <!-- ext-master-secret --> not CNSA compliant <bcp14>MAY</bcp14> offer additional cipher suites, but any a
dditional cipher suites <bcp14>MUST</bcp14> appear after the CNSA cipher suites
<section anchor="tls12-sig-algs" title="The signature_algorithms Extension"> in the ClientHello message.
<t>A CNSA (D)TLS client MUST include and a CNSA (D)TLS server MUST also accept t
he "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 th
e "signature_algorithms" extensions as specified in <xref target="RFC8446" />:
<list style="empty">
<t>ecdsa_secp384r1_sha384</t>
<t>rsa_pkcs1_sha384</t>
</list>
</t> </t>
<t>A CNSA (D)TLS server <bcp14>MUST</bcp14> accept one of the CNSA
<t>And, if supported, the client SHOULD offer and/or the server SHOULD also acce Suites above if they are offered in the ClientHello message before
pt: accepting a non-CNSA-compliant suite.
<list style="empty">
<t>rsa_pss_pss_sha384</t>
<t>rsa_pss_rsae_sha384</t>
</list>
</t> </t>
<t>If interoperability is not desired with non-CNSA-compliant clients or
<t>Following the guidance in <xref target="RFC8603" />, CNSA (D)TLS servers MUST servers, then the session <bcp14>MUST</bcp14> fail if no CNSA Suites are
only accept ECDSA or RSA for signatures on ServerKeyExchange messages and for c offered or accepted.
ertification path validation.
</t> </t>
<section anchor="ext-master-secret" numbered="true" toc="default">
<t>Other client offerings MAY be included to indicate the acceptable signature a <name>The "extended_master_secret" Extension</name>
lgorithms in cipher suites that are offered for interoperability with servers no <t>A CNSA (D)TLS client <bcp14>SHOULD</bcp14> include and a CNSA
t compliant with CNSA and to indicate the signature algorithms that are acceptab (D)TLS server <bcp14>SHOULD</bcp14> accept the
le for ServerKeyExchange messages and for certification path validation in non-c "extended_master_secret" extension as specified in <xref
ompliant CNSA (D)TLS connections. These offerings MUST NOT be accepted by a CNSA target="RFC7627" format="default"/>. See <xref target="RFC7627"
compliant (D)TLS server. sectionFormat="of" section="1" format="default"/> for security
concerns when this extension is not used.
</t> </t>
</section>
</section> <!-- tls12-sig-algs --> <section anchor="tls12-sig-algs" numbered="true" toc="default">
<name>The "signature_algorithms" Extension</name>
<t>A CNSA (D)TLS client <bcp14>MUST</bcp14> include and a CNSA (D)TLS se
rver <bcp14>MUST</bcp14> also accept the "signature_algorithms" extension. The C
NSA (D)TLS client <bcp14>MUST</bcp14> offer and the
CNSA (D)TLS server <bcp14>MUST</bcp14> also accept at least one of the followi
ng values in the "signature_algorithms" extensions as specified in <xref target=
"RFC8446" format="default"/>:
<section anchor="tls12-sig-algs-cert-ext" title="The signature_algorithms_cert E </t>
xtension"> <ul empty="true" spacing="normal">
<li>ecdsa_secp384r1_sha384</li>
<li>rsa_pkcs1_sha384</li>
</ul>
<t>And, if supported, the client <bcp14>SHOULD</bcp14> offer and/or the
server <bcp14>SHOULD</bcp14> also accept:
<t>A CNSA (D)TLS client MAY include the "signature_algorithms_cert" extension. </t>
CNSA (D)TLS servers MUST process the "signature_algorithms_cert" extension if i <ul empty="true" spacing="normal">
t is offered per Section 4.2.3 of <xref target="RFC8446" />. <li>rsa_pss_pss_sha384</li>
<li>rsa_pss_rsae_sha384</li>
</ul>
<t>Following the guidance in <xref target="RFC8603" format="default"/>,
CNSA (D)TLS servers <bcp14>MUST</bcp14> only accept ECDSA or RSA for signatures
on ServerKeyExchange messages and for certification path validation.
</t> </t>
<t>Other client offerings <bcp14>MAY</bcp14> be included to indicate the
<t>Both CNSA (D)TLS clients and servers MUST use one of the following values for acceptable signature algorithms in cipher suites that are offered for interoper
certificate path validation: ability with servers not compliant with CNSA and to indicate the signature algor
ithms that are acceptable for ServerKeyExchange messages and for certification p
<list> ath validation in non-compliant CNSA (D)TLS connections. These offerings <bcp14>
<t>ecdsa_secp384r1_sha384</t> MUST NOT</bcp14> be accepted by a CNSA-compliant (D)TLS server.
<t>rsa_pkcs1_sha384</t>
</list>
</t> </t>
</section>
<t>And, if supported, SHOULD offer/accept: <section anchor="tls12-sig-algs-cert-ext" numbered="true" toc="default">
<name>The "signature_algorithms_cert" Extension</name>
<list> <t>A CNSA (D)TLS client <bcp14>MAY</bcp14> include the
<t>rsa_pss_pss_sha384</t> "signature_algorithms_cert" extension. CNSA (D)TLS servers
<t>rsa_pss_rsae_sha384</t> <bcp14>MUST</bcp14> process the "signature_algorithms_cert" extension
</list> if it is offered per <xref target="RFC8446" sectionFormat="of"
section="4.2.3" format="default"/>.
</t> </t>
<t>Both CNSA (D)TLS clients and servers <bcp14>MUST</bcp14> use one of t he following values for certificate path validation:
</section> <!-- tls12-sig-algs-cert-ext --> </t>
<ul empty="true" spacing="normal">
<section anchor="tls12-cert-request" title="The CertificateRequest Message"> <li>ecdsa_secp384r1_sha384</li>
<li>rsa_pkcs1_sha384</li>
<t>When a CNSA (D)TLS server is configured to authenticate the client, the serve </ul>
r MUST include in its CertificateRequest.supported_signature_algorithms <xref ta <t>And, if supported, <bcp14>SHOULD</bcp14> offer/accept:
rget="RFC5246" /> offer:
<list>
<t>ecdsa_secp384r1_sha384</t>
<t>rsa_pkcs1_sha384</t>
</list>
</t>
<t>And, if supported as specified in <xref target="RFC8446" />, SHOULD offer/acc </t>
ept: <ul empty="true" spacing="normal">
<li>rsa_pss_pss_sha384</li>
<li>rsa_pss_rsae_sha384</li>
</ul>
</section>
<list> <section anchor="tls12-cert-request" numbered="true" toc="default">
<t>rsa_pss_pss_sha384</t> <name>The CertificateRequest Message</name>
<t>rsa_pss_rsae_sha384</t> <t>When a CNSA (D)TLS server is configured to authenticate the client, t
</list> he server <bcp14>MUST</bcp14> include the following values in its CertificateReq
</t> uest.supported_signature_algorithms <xref target="RFC5246" format="default"/> of
fer:
</section> <!-- tls12-cert-request --> </t>
<ul empty="true" spacing="normal">
<li>ecdsa_secp384r1_sha384</li>
<li>rsa_pkcs1_sha384</li>
</ul>
<t>And, if supported as specified in <xref target="RFC8446" format="defa
ult"/>, <bcp14>SHOULD</bcp14> offer/accept:
<section anchor="tls12-cert-verify" title="The CertificateVerify Message"> </t>
<ul empty="true" spacing="normal">
<li>rsa_pss_pss_sha384</li>
<li>rsa_pss_rsae_sha384</li>
</ul>
</section>
<t>A CNSA (D)TLS client MUST use ECDSA or RSA when sending the CertificateVerify <section anchor="tls12-cert-verify" numbered="true" toc="default">
message. CNSA (D)TLS Servers MUST only accept ECDSA or RSA in the CertificateV <name>The CertificateVerify Message</name>
erify message. <t>A CNSA (D)TLS client <bcp14>MUST</bcp14> use ECDSA or RSA when sendin
g the CertificateVerify message. CNSA (D)TLS servers <bcp14>MUST</bcp14> only a
ccept ECDSA or RSA in the CertificateVerify message.
</t> </t>
</section>
</section> <!-- tls12-cert-verify --> <section anchor="tls12-ske-message" numbered="true" toc="default">
<name>The Signature in the ServerKeyExchange Message</name>
<section anchor="tls12-ske-message" title="The Signature in the ServerKeyExchang <t>A CNSA (D)TLS server <bcp14>MUST</bcp14> sign the ServerKeyExchange m
e Message"> essage using ECDSA or RSA.
<t>A CNSA (D)TLS server MUST sign the ServerKeyExchange message using ECDSA or R
SA.
</t> </t>
</section>
</section> <!-- tls12-ske-message" --> <section anchor="tls12-cert-status" numbered="true" toc="default">
<name>Certificate Status</name>
<section anchor="tls12-cert-status" title="Certificate Status"> <t>Certificate Authorities (CAs) providing certificates to a CNSA (D)TLS
server or client <bcp14>MUST</bcp14> provide certificate revocation
<t>Certificate Authorities providing certificates to a CNSA (D)TLS server or cli status information via a Certificate Revocation List (CRL)
ent MUST provide certificate revocation status information via a Certificate Rev distribution point or using the Online Certificate Status Protocol
ocation List (CRL) distribution point or using the Online Certificate Status Pro (OCSP). A CNSA client <bcp14>SHOULD</bcp14> request it according to
tocol (OCSP). A CNSA client SHOULD request it according to <xref target="RFC844 <xref target="RFC8446" format="default" sectionFormat="of"
6" /> Section 4.4.2.1. If OCSP is supported, the (D)TLS server SHOULD provide O section="4.4.2.1"/>. If OCSP is supported, the (D)TLS server
CSP responses in the "CertificateStatus" message. <bcp14>SHOULD</bcp14> provide OCSP responses in the
CertificateStatus message.
</t> </t>
</section>
</section> <!-- tls12-cert-status --> </section>
</section> <!-- tls12-reqts -->
<section anchor="tls13-reqts" title="(D)TLS 1.3 Requirements">
<t>The CNSA (D)TLS client MUST offer the following CipherSuite in the ClientHell <section anchor="tls13-reqts" numbered="true" toc="default">
o: <name>(D)TLS 1.3 Requirements</name>
<t>The CNSA (D)TLS client <bcp14>MUST</bcp14> offer the following cipher
suite in the ClientHello:
<list style="empty">
<t>TLS_AES_256_GCM_SHA384</t>
</list>
</t> </t>
<ul empty="true" spacing="normal">
<li>TLS_AES_256_GCM_SHA384</li>
</ul>
<t>The CNSA (D)TLS client MUST include at least one of the following values in " <t>The CNSA (D)TLS client <bcp14>MUST</bcp14> include at least one of
supported_groups": the following values in the "supported_groups" extension:
<list style="empty">
<t>ECDHE: secp384r1</t>
<t>DHE: ffdhe3072</t>
<t>DHE: ffdhe4096</t>
</list>
</t> </t>
<ul empty="true" spacing="normal">
<t>The CNSA cipher suite MUST be the first (most preferred) cipher suites in the <li>ECDHE: secp384r1</li>
ClientHello message and in the extensions. <li>DHE: ffdhe3072</li>
<li>DHE: ffdhe4096</li>
</ul>
<t>The CNSA cipher suite <bcp14>MUST</bcp14> be the first (most
preferred) cipher suite in the ClientHello message and in the
extensions.
</t> </t>
<t>A CNSA (D)TLS client that offers interoperability with servers that are
<t>A CNSA (D)TLS client that offers interoperability with servers that are not CNSA compliant <bcp14>MAY</bcp14> offer additional cipher suites, but any ad
not CNSA compliant MAY offer additional cipher suites, but any additional ditional
cipher suites MUST appear after the CNSA compliant cipher suites in the cipher suites <bcp14>MUST</bcp14> appear after the CNSA-compliant cipher suites
in the
ClientHello message. ClientHello message.
</t> </t>
<t>A CNSA (D)TLS server <bcp14>MUST</bcp14> accept one of the CNSA algorit
<t>A CNSA (D)TLS server MUST accept one of the CNSA algorithms listed above if t hms listed above if they are offered in the ClientHello message.
hey are offered in the ClientHello message.
</t> </t>
<t>If interoperability is not desired with non-CNSA-compliant clients or s
<t>If interoperability is not desired with non-CNSA compliant clients or servers ervers, then the session <bcp14>MUST</bcp14> fail if no CNSA Suites are offered
, then the session MUST fail if no CNSA suites are offered or accepted. or accepted.
</t> </t>
<section anchor="tls13-sig-algs" numbered="true" toc="default">
<name>The "signature_algorithms" Extension</name>
<t>A CNSA (D)TLS client <bcp14>MUST</bcp14> include the "signature_algor
ithms" extension. The CNSA (D)TLS client <bcp14>MUST</bcp14> offer at least one
of the following values in the "signature_algorithms" extension:
<section anchor="tls13-sig-algs" title="The &quot;signature_algorithms&quot; Ext </t>
ension"> <ul empty="true" spacing="normal">
<li>ecdsa_secp384r1_sha384</li>
<li>rsa_pss_pss_sha384</li>
<li>rsa_pss_rsae_sha384</li>
</ul>
<t>Clients that allow negotiating TLS 1.2 <bcp14>MAY</bcp14> offer rsa_p
kcs1_sha384 for use with TLS 1.2. Other offerings <bcp14>MAY</bcp14> be include
d to indicate the acceptable signature algorithms in cipher suites that are offe
red for interoperability with servers not compliant with CNSA in non-compliant C
NSA (D)TLS connections. These offerings <bcp14>MUST NOT</bcp14> be accepted by
a CNSA-compliant (D)TLS server.
</t>
</section>
<t>A CNSA (D)TLS client MUST include the "signature_algorithms" extension. The C <section anchor="tls13-sig-algs-cert" numbered="true" toc="default">
NSA (D)TLS client MUST offer at least one of the following values in the "signat <name>The "signature_algorithms_cert" Extension</name>
ure_algorithms" extension: <t>A CNSA (D)TLS client <bcp14>SHOULD</bcp14> include the "signature_alg
orithms_cert" extension. And, if offered, the CNSA (D)TLS client <bcp14>MUST</bc
p14> offer at least one of the following values in the "signature_algorithms_cer
t" extension:
<list style="empty">
<t>ecdsa_secp384r1_sha384</t>
<t>rsa_pss_pss_sha384</t>
<t>rsa_pss_rsae_sha384</t>
</list>
</t> </t>
<ul empty="true" spacing="normal">
<t>Clients that allow negotiating TLS 1.2 MAY offer rsa_pkcs1_sha384 for use wit <li>ecdsa_secp384r1_sha384</li>
h TLS 1.2. Other offerings MAY be included to indicate the acceptable signature <li>rsa_pkcs1_sha384</li>
algorithms in cipher suites that are offered for interoperability with servers </ul>
not compliant with CNSA in non-compliant CNSA (D)TLS connections. These offerin <t>And, if supported, <bcp14>SHOULD</bcp14> offer:
gs MUST NOT be accepted by a CNSA compliant (D)TLS server.
</t> </t>
<ul empty="true" spacing="normal">
</section> <!-- tls13-sig-algs --> <li>rsa_pss_pss_sha384</li>
<li>rsa_pss_rsae_sha384</li>
<section anchor="tls13-sig-algs-cert" title="The &quot;signature_algorithms_cert </ul>
&quot; Extension"> <t>Following the guidance in <xref target="RFC8603" format="default"/>,
CNSA (D)TLS servers <bcp14>MUST</bcp14> only accept ECDSA or RSA for certificate
<t>A CNSA (D)TLS client SHOULD include the "signature_algorithms_cert" extension path validation.
. And if offered, the CNSA (D)TLS client MUST offer at least one of the followin
g values in the "signature_algorithms_cert" extension:
<list style="empty">
<t>ecdsa_secp384r1_sha384</t>
<t>rsa_pkcs1_sha384</t>
</list>
</t> </t>
<t>Other offerings <bcp14>MAY</bcp14> be included to indicate the signat
<t>And, if supported, SHOULD offer: ure algorithms that are acceptable for certification path validation in non-comp
<list style="empty"> liant CNSA (D)TLS connections. These offerings <bcp14>MUST NOT</bcp14> be accept
<t>rsa_pss_pss_sha384</t> ed by a CNSA-compliant (D)TLS server.
<t>rsa_pss_rsae_sha384</t>
</list>
</t> </t>
</section>
<t>Following the guidance in <xref target="RFC8603" />, CNSA (D)TLS servers MUST <section anchor="tls13-early-data" numbered="true" toc="default">
only accept ECDSA or RSA for certificate path validation. <name>The "early_data" Extension</name>
<t>A CNSA (D)TLS client or server <bcp14>MUST NOT</bcp14> include the
"early_data" extension. See <xref target="RFC8446"
format="default" sectionFormat="of" section="2.3" /> for security concer
ns.
</t> </t>
</section>
<t>Other offerings MAY be included to indicate the signature algorithms that are <section anchor="tls13-resumption" numbered="true" toc="default">
acceptable for certification path validation in non-compliant CNSA (D)TLS conne <name>Resumption</name>
ctions. These offerings MUST NOT be accepted by a CNSA compliant (D)TLS server. <t>A CNSA (D)TLS server <bcp14>MAY</bcp14> send a CNSA (D)TLS client a
NewSessionTicket message to enable resumption. A CNSA (D)TLS client
<bcp14>MUST</bcp14> request "psk_dhe_ke" via the
"psk_key_exchange_modes" ClientHello extension to resume a session. A
CNSA (D)TLS client <bcp14>MUST</bcp14> 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.
</t> </t>
</section>
</section> <!-- tls13-sig-algs-cert --> <section anchor="tls13-cert-stat" numbered="true" toc="default">
<name>Certificate Status</name>
<section anchor="tls13-early-data" title="The &quot;early_data&quot; Extension"> <t>Certificate Authorities (CAs) providing certificates to a CNSA (D)TLS
server or client <bcp14>MUST</bcp14> provide certificate revocation status info
<t>A CNSA (D)TLS client or server MUST NOT include the "early_data" extension. rmation via a Certificate Revocation List (CRL) distribution point or using the
See Section 2.3 <xref target="RFC8446" /> for security concerns. Online Certificate Status Protocol (OCSP). A CNSA client <bcp14>SHOULD</bcp14>
request it according to <xref target="RFC8446" format="default" sectionFormat="o
f" section="4.4.2.1"/>. If OCSP is supported, the (D)TLS server <bcp14>SHOULD</
bcp14> provide OCSP responses in the "CertificateEntry".
</t> </t>
</section>
</section> <!-- tls13-early-data --> </section>
<section anchor="tls13-resumption" title="Resumption">
<t>A CNSA (D)TLS server MAY send a CNSA (D)TLS client a NewSessionTicket message <section anchor="sec-considerations" numbered="true" toc="default">
to enable resumption. A CNSA (D)TLS client MUST request "psk_dhe_ke" via the ps <name>Security Considerations</name>
k_key_exchange_modes ClientHello extension to resume a session. A CNSA (D)TLS cl <t>Most of the security considerations for this document are described
ient MUST offer ECDHE with SHA-384 and/or DHE with SHA-384 in the "supported_gro in <xref target="RFC5246" format="default"/>, <xref target="RFC8446"
ups" and/or "key_share" extensions. format="default"/>, <xref target="RFC6347" format="default"/>, and <xref
target="RFC9147" format="default"/>. In addition, the security
considerations for Elliptic Curve Cryptography (ECC) related to TLS are
described in <xref target="RFC8422" format="default"/>, <xref
target="RFC5288" format="default"/>, and <xref target="RFC5289"
format="default"/>. Readers should consult those documents.
</t> </t>
<t>In order to meet the goal of a consistent security level for the entire
</section> <!-- tls13-resumption --> cipher suite, CNSA (D)TLS implementations <bcp14>MUST</bcp14> only use the elli
ptic curves, RSA schemes, and Finite Fields defined in <xref target="ecc-curves"
<section anchor="tls13-cert-stat" title="Certificate Status"> format="default"/>, <xref target="rsa-schemes" format="default"/>, and <xref ta
rget="ff-groups" format="default"/>, respectively. If this is not the case, the
<t>Certificate Authorities providing certificates to a CNSA (D)TLS server or cli n security may be weaker than is required.
ent MUST provide certificate revocation status information via a Certificate Rev
ocation List (CRL) distribution point or using the Online Certificate Status Pro
tocol (OCSP). A CNSA client SHOULD request it according to <xref target="RFC844
6" /> Section 4.4.2.1. If OCSP is supported, the (D)TLS server SHOULD provide O
CSP responses in the "CertificateEntry".
</t> </t>
<t>As noted in TLS version 1.3 <xref target="RFC8446" format="default"/>,
TLS does not provide inherent replay protections for early data. For this reaso
n, this profile forbids the use of early data.
</t>
</section>
</section> <!-- tls13-cert-stat --> <section anchor="iana-considerations" numbered="true" toc="default">
<name>IANA Considerations</name>
<t>This document has no IANA actions.</t>
</section>
</section> <!-- tls13-reqts --> </middle>
<back>
<section anchor="sec-considerations" title="Security Considerations"> <references>
<name>References</name>
<references>
<name>Normative References</name>
<t>Most of the security considerations for this document are described in <xref <reference anchor="AES" target="https://nvlpubs.nist.gov/nistpubs/fips/N
target="RFC5246" />, <xref target="RFC8446" />, <xref target="RFC6347" />, and < IST.FIPS.197.pdf">
xref target="ID.dtls13" />. In addition, the security consideration for ECC rel <front>
ated to TLS are described in <xref target="RFC8422" />, <xref target="RFC5288" / <title>Announcing the ADVANCED ENCRYPTION STANDARD (AES)</title>
> and <xref target="RFC5289" />. Readers should consult those documents. <author>
</t> <organization>National Institute of Standards and Technology</orga
nization>
</author>
<date month="November" year="2001"/>
</front>
<seriesInfo name="FIPS" value="197"/>
<seriesInfo name="DOI" value="10.6028/NIST.FIPS.197"/>
</reference>
<t>In order to meet the goal of a consistent security level for the entire ciphe <reference anchor="CNSA" target="https://www.cnss.gov/CNSS/issuances/Policies.cf
r suite, CNSA (D)TLS implementations MUST only use the Elliptic Curves, RSA sche m">
mes and Finite Fields defined in <xref target="ecc-curves" />, <xref target="rsa <front>
-schemes" />, and <xref target="ff-groups" /> respectively. If this is not the <title>Use of Public Standards for Secure Information Sharing</title
case, then security may be weaker than is required. >
</t> <author>
<organization>Committee for National Security Systems</organizatio
n>
</author>
<date month="October" year="2016"/>
</front>
<seriesInfo name="CNSSP" value="15"/>
</reference>
<t>As noted in TLS version 1.3 <xref target="RFC8446" />, TLS does not provide i <!-- [DSS] The URL below is correct. Also found https://csrc.nist.gov/publicat
nherent replay protections for early data. For this reason, this profile forbid ions/detail/fips/186/4/final -->
s the use of early data.
</t>
</section> <!-- sec-considerations --> <reference anchor="DSS" target="https://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS
.186-4.pdf">
<front>
<title>Digital Signature Standard (DSS)</title>
<author>
<organization>National Institute of Standards and Technology</orga
nization>
</author>
<date month="July" year="2013"/>
</front>
<seriesInfo name="FIPS PUB" value="186-4"/>
<seriesInfo name="DOI" value="10.6028/NIST.FIPS.186-4"/>
</reference>
<section anchor="iana-considerations" title="IANA Considerations"> <!-- [GCM] The URL below is correct. Also found https://csrc.nist.gov/publicat ions/detail/sp/800-38d/final -->
<t>This document has no IANA actions.</t> <reference anchor="GCM" target="https://nvlpubs.nist.gov/nistpubs/Legacy/SP/nist
specialpublication800-38d.pdf">
<front>
<title>Recommendation for Block Cipher Modes of Operation:
Galois/Counter Mode (GCM) and GMAC</title>
<author fullname="Morris Dworkin" initials="M" surname="Dworkin"/>
<date month="November" year="2007"/>
</front>
<seriesInfo name="NIST Special Publication" value="800-38D"/>
<seriesInfo name="DOI" value="10.6028/NIST.SP.800-38D"/>
</reference>
</section> <!-- iana-considerations --> <!-- [PWKE-A] The URL below is correct. Also found https://csrc.nist.gov/public ations/detail/sp/800-56a/rev-3/final -->
</middle> <reference anchor="PWKE-A" target="https://nvlpubs.nist.gov/nistpubs/SpecialPubl
ications/NIST.SP.800-56Ar3.pdf">
<front>
<title>Recommendation for Pair-Wise Key Establishment Schemes
Using Discrete Logarithm Cryptography</title>
<author fullname="Elaine Barker" initials="E" surname="Barker"/>
<author fullname="Lily Chen" initials="L" surname="Chen"/>
<author fullname="Allen Roginsky" initials="A" surname="Roginsky"/>
<author fullname="Apostol Vassilev" initials="A" surname="Vassilev"/
>
<author fullname="Richard Davis" initials="R" surname="Davis"/>
<date month="April" year="2018"/>
</front>
<seriesInfo name="NIST Special Publication" value="800-56A Revision 3"
/>
<seriesInfo name="DOI" value="10.6028/NIST.SP.800-56Ar3"/>
</reference>
<back> <!-- ===== BACK MATTER ===== --> <!-- [PWKE-B] The URL below is correct. Also found https://csrc.nist.gov/publica tions/detail/sp/800-56b/rev-2/final -->
<references title="Normative References"> <reference anchor="PWKE-B" target="https://nvlpubs.nist.gov/nistpubs/SpecialPubl
ications/NIST.SP.800-56Br2.pdf">
<front>
<title>Recommendation for Pair-Wise Key Establishment Schemes Using
Integer Factorization Cryptography</title>
<author fullname="Elaine Barker" initials="E" surname="Barker"/>
<author fullname="Lily Chen" initials="L" surname="Chen"/>
<author fullname="Allen Roginsky" initials="A" surname="Roginsky"/>
<author fullname="Apostol Vassilev" initials="A" surname="Vassilev"/
>
<author fullname="Richard Davis" initials="R" surname="Davis"/>
<author fullname="Scott Simon" initials="S" surname="Simon"/>
<date month="March" year="2019"/>
</front>
<seriesInfo name="NIST Special Publication" value="800-56B Revision 2"
/>
<seriesInfo name="DOI" value="10.6028/NIST.SP.800-56Br2"/>
</reference>
<reference anchor="AES" target="https://nvlpubs.nist.gov/nistpubs/fips/NIST.FIPS <!-- [SHS] The URL below is correct. Also found
.197.pdf"> https://csrc.nist.gov/publications/detail/fips/180/4/final -->
<front>
<title>Specification for the Advanced Encryption Standard (AES)</title>
<author>
<organization>National Institute of Standards and Technology</organization>
</author>
<date month="November" year="2001" />
</front>
<seriesInfo name="FIPS" value="197"></seriesInfo>
</reference> <!-- AES -->
<reference anchor="CNSA" target="https://www.cnss.gov/CNSS/issuances/Policies.cf <reference anchor="SHS" target="https://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS
m"> .180-4.pdf">
<front> <front>
<title>Use of Public Standards for Secure Information Sharing</title> <title>Secure Hash Standard (SHS)</title>
<author> <author>
<organization>Committee for National Security Systems</organization> <organization>National Institute of Standards and Technology (NIST
</author> )</organization>
<date month="October" year="2016"></date> </author>
</front> <date month="August" year="2015"/>
<seriesInfo name="CNSSP" value="15" /> </front>
</reference> <!-- CNSA --> <seriesInfo name="DOI" value="10.6028/NIST.FIPS.180-4"/>
<seriesInfo name="FIPS PUB" value="180-4"/>
</reference>
<reference anchor="DSS" target="http://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS. <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
186-4.pdf"> C.2119.xml"/>
<front> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
<title>Digital Signature Standard (DSS)</title> FC.5246.xml"/>
<author> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
<organization>National Institute of Standards and Technology</organization> FC.5288.xml"/>
</author> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
<date month="July" year="2013" /> FC.5289.xml"/>
</front> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
<seriesInfo name="NIST Federal Information Processing Standard" value="186-4" /> FC.6347.xml"/>
</reference> <!-- DSS --> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.7627.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.7919.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.8017.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.8174.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.8422.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.8446.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.8603.xml"/>
<reference anchor="GCM" target="https://nvlpubs.nist.gov/nistpubs/Legacy/SP/nist <!-- [ID.dtls13] [I-D.ietf-tls-dtls13] companion document RFC 9147; in AUTH48 a
specialpublication800-38d.pdf"> s of 8/11/21 -->
<front>
<title>Recommendation for Block Cipher Modes of Operation: Galois/Counter Mode
(GCM) and GMAC</title>
<author>
<organization>National Institute of Standards and Technology</organization>
</author>
<date month="November" year="2007" />
</front>
<seriesInfo name="NIST Special Publication" value="800-38D" />
</reference> <!-- GCM -->
<reference anchor="PWKE-A" target="https://nvlpubs.nist.gov/nistpubs/SpecialPubl ications/NIST.SP.800-56Ar3.pdf"> <reference anchor='RFC9147'>
<front> <front>
<title>Recommendation for Pair-Wise Key Establishment Schemes Using Discrete L <title>The Datagram Transport Layer Security (DTLS) Protocol Version 1.3</title>
ogarithm Cryptography</title>
<author>
<organization>National Institute of Standards and Technology</organization>
</author>
<date month="April" year="2018" />
</front>
<seriesInfo name="NIST Special Publication" value="800-56A, Revision 3" />
</reference> <!-- PWKE-A -->
<reference anchor="PWKE-B" target="https://nvlpubs.nist.gov/nistpubs/SpecialPubl <author initials='E' surname='Rescorla' fullname='Eric Rescorla'>
ications/NIST.SP.800-56Br2.pdf"> <organization />
<front> </author>
<title>Recommendation for Pair-Wise Key Establishment Schemes Using Integer Fa
ctorization Cryptography</title>
<author>
<organization>National Institute of Standards and Technology</organization>
</author>
<date month="March" year="2019" />
</front>
<seriesInfo name="NIST Special Publication" value="800-56B, Revision 2" />
</reference> <!-- PWKE-B -->
<reference anchor="SHS" target="https://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS <author initials='H' surname='Tschofenig' fullname='Hannes Tschofenig'>
.180-4.pdf"> <organization />
<front> </author>
<title>Secure Hash Standard (SHS)</title>
<author>
<organization>National Institute of Standards and Technology</organization>
</author>
<date month="August" year="2015" />
</front>
<seriesInfo name="NIST Federal Information Processing Standard" value="180-4" />
</reference> <!-- SHS -->
&rfc2119; <author initials='N' surname='Modadugu' fullname='Nagendra Modadugu'>
&rfc5246; <organization />
&rfc5288; </author>
&rfc5289;
&rfc6347;
&rfc7627;
&rfc7919;
&rfc8017;
&rfc8174;
&rfc8422;
&rfc8446;
&rfc8603;
<reference anchor="ID.dtls13" target="https://datatracker.ietf.org/doc/draft-iet <date month='August' year='2021' />
f-tls-dtls13/">
<front>
<title>The Datagram Transport Layer Security (DTLS) Protocol Version 1.3</titl
e>
<author initials="E." surname="Rescorla" />
<author initials="H." surname="Tschofenig" />
<author initials="N." surname="Modadugu" />
<date month="May" year="2020" />
</front>
<annotation>Work in progress.</annotation>
</reference> <!-- dtls13 -->
</references> </front>
<seriesInfo name="RFC" value="9147"/>
<seriesInfo name="DOI" value="10.17487/RFC9147"/>
</reference>
</references>
<references>
<name>Informative References</name>
<references title="Informative References"> <!-- [SP80059] The URL below is correct. Also found https://csrc.nist.gov/publi cations/detail/sp/800-59/final -->
<reference anchor="SP80059" target="https://nvlpubs.nist.gov/nistpubs/Legacy/SP/ <reference anchor="SP80059" target="https://nvlpubs.nist.gov/nistpubs/Le
nistspecialpublication800-59.pdf"> gacy/SP/nistspecialpublication800-59.pdf">
<front> <front>
<title>Guideline for Identifying an Information System as a National Securit <title>Guideline for Identifying an Information System as a
y System</title> National Security System</title>
<author> <author fullname="William Barker" initials="W" surname="Barker"/>
<organization>National Institute of Standards and Technology</organization <date month="August" year="2003"/>
> </front>
</author> <seriesInfo name="DOI" value="10.6028/NIST.SP.800-59"/>
<date month="August" year="2003" /> <seriesInfo name="NIST Special Publication" value="800-59"/>
</front> </reference>
<seriesInfo name="Special Publication 800" value="59" />
</reference> <!-- SP80059 -->
<reference anchor="SECG" target="http://www.secg.org/download/aid-784/sec2-v2.pd <reference anchor="SECG" target="https://www.secg.org/sec2-v2.pdf">
f"> <front>
<front> <title>SEC 2: Recommended Elliptic Curve Domain Parameters</title>
<title>SEC 2: Recommended Elliptic Curve Domain Parameters</title> <author fullname="Daniel Brown" initials="D." surname="Brown"/>
<author initials="D." surname="Brown" /> <date month="February" year="2010"/>
<date month="February" year="2010" /> </front>
</front> <seriesInfo name="Version" value="2.0"/>
</reference> <!-- SECG --> </reference>
</references> </references>
</references>
</back> <!-- ===== END BACK MATTER ===== --> </back>
</rfc> </rfc>
 End of changes. 150 change blocks. 
709 lines changed or deleted 712 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/