wdiff rfc9151xml2.original.xml rfc9151.xml

<?xml version="1.0" encoding="UTF-8"?>

<!-- ===== CONTEXT SETTINGS ===== -->

<!-- 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. --> "rfc2629-xhtml.ent">

<rfc category="info" xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft-cooley-cnsa-dtls-tls-profile-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/subsections in ToC -->

    <!-- Choose options for the references. The tags used are the anchor attributes of the references. -->

    <?rfc symrefs="yes"?>      <!-- yes - use symbolic references in xref tags -->
    <?rfc sortrefs="yes" ?>    <!-- yes - If symrefs also yes, sort references in 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 items -->

<!-- end Processing Instructions -->

<!-- ===== END CONTEXT SETTINGS ===== --> number="9151" obsoletes="" updates="" submissionType="independent" category="info" xml:lang="en" tocInclude="true" tocDepth="2"
symRefs="true" sortRefs="true" version="3">

<front>     <!-- ===== FRONT MATTER ===== -->

    <title abbrev="CNSA Suite TLS Profile">Commercial Profile for (D)TLS">Commercial National Security Algorithm (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">
      <organization abbrev="NSA">National Security Agency</organization>
        <address><email>decoole@nsa.gov</email></address>
      <address>
        <email>decoole@nsa.gov</email>
      </address>
    </author>
    <date year="2021"/> <!-- Current month and day will be filled in. -->

    <!-- Meta-data Declarations --> year="2021" month="August" />

    <area>Security</area>
    <workgroup>Network Working Group</workgroup>

    <!-- There must be an abstract. -->

<abstract>
      <t>This document defines a base profile for TLS protocol versions 1.2
      and 1.3, 1.3 as well as DTLS protocol versions 1.2 and 1.3 for use with the United States
      US Commercial National Security Algorithm (CNSA) Suite.
      </t>
      <t>The profile applies to the capabilities, configuration, and operation
      of all components of US National Security Systems that use TLS or DTLS.
      It is also appropriate for all other US Government systems that process
      high-value information.
</t>
      <t>The profile is made publicly available here for use by developers and
      operators of these and any other system deployments.
</t>
    </abstract>
  </front>     <!-- ===== END FRONT MATTER ===== -->

<middle>     <!-- ===== DOCUMENT BODY ===== -->

<section anchor="intro" title="Introduction"> numbered="true" toc="default">
      <name>Introduction</name>
      <t>This document specifies a profile of TLS version 1.2 <xref target="RFC5246" /> format="default"/> and TLS version 1.3 <xref target="RFC8446" />, format="default"/> as well as DTLS version 1.2 <xref target="RFC6347"/> target="RFC6347" format="default"/> and DTLS version 1.3 <xref target="ID.dtls13" /> target="RFC9147" format="default"/> for use by applications that support the National Security Agency's (NSA) Commercial National Security Algorithm (CNSA) Suite <xref target="CNSA" />. format="default"/>.  The profile applies to the capabilities, configuration, and operation of all components of US National Security Systems <xref target="SP80059" />. format="default"/>. It is also appropriate for all other US Government systems that process high-value information. It is made publicly available for use by developers and operators of these and any other system deployments.
</t>
      <t>This document does not define any new cipher suites; instead, it defines a CNSA compliant CNSA-compliant profile of TLS and DTLS, and the cipher suites defined in <xref target="RFC5288" />, format="default"/>, <xref target="RFC5289" />, format="default"/>, and <xref target="RFC8446" />. format="default"/>.  This profile uses only algorithms in the CNSA Suite.
</t>
      <t>The reader is assumed to have familiarity with the TLS 1.2 and 1.3 as well as the DTLS 1.2 and 1.3 protocol specifications: <xref target="RFC5246" />, <xref target="RFC6347"/>, format="default"/>, <xref target="RFC8446" />, format="default"/>,  <xref target="RFC6347" format="default"/>, and <xref target="ID.dtls13" />. target="RFC9147" format="default"/>, respectively.  All MUST-level <bcp14>MUST</bcp14>-level requirements from the protocol documents apply throughout this profile; they are generally not repeated.  This profile contains changes that elevate some SHOULD-level <bcp14>SHOULD</bcp14>-level options to MUST-level; <bcp14>MUST</bcp14>-level; this profile also contains changes that elevate some MAY-level <bcp14>MAY</bcp14>-level options to SHOULD-level <bcp14>SHOULD</bcp14>-level or MUST-level. <bcp14>MUST</bcp14>-level.  All options that are not mentioned in this profile remain at their original requirement level.
</t>
    </section>  <!-- intro -->

<section anchor="cnsa" title="The Commercial National Security Algorithm Suite"> numbered="true" toc="default">
      <name>CNSA</name>
      <t>The National Security Agency (NSA) profiles commercial cryptographic
      algorithms and protocols as part of its mission to support secure,
      interoperable communications for US Government National Security Systems. To this
      end, it publishes guidance both to assist with the US Government
      transition to new algorithms, algorithms and to provide vendors - -- and the Internet
      community in general - -- with information concerning their proper use and
      configuration.
</t>
      <t>Recently, cryptographic transition plans have become overshadowed by the prospect of the development of a cryptographically-relevant cryptographically relevant quantum computer.  The NSA has established the CNSA Suite to provide vendors and IT users near-term flexibility in meeting their Information Assurance (IA) interoperability requirements. The purpose behind this flexibility is to avoid having vendors and customers make two major transitions in a relatively short timeframe, as we anticipate a need to shift to quantum-resistant cryptography in the near future.
</t>

<t>NSA
      <t>The NSA is authoring a set of RFCs, including this one, to provide
      updated guidance concerning the use of certain commonly available
      commercial algorithms in IETF protocols.  These RFCs can be used in
      conjunction with other RFCs and cryptographic guidance (e.g., NIST
      Special Publications) to properly protect Internet traffic and
      data-at-rest for US Government National Security Systems.
</t>
    </section> <!-- cnsa -->

<section anchor="terms" title="Terminology"> numbered="true" toc="default">
      <name>Terminology</name>
      <t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>", "<bcp14>MAY</bcp14>", and "OPTIONAL" "<bcp14>OPTIONAL</bcp14>" in this document are to be interpreted as described in BCP 14 BCP&nbsp;14 <xref target="RFC2119" /> format="default"/> <xref target="RFC8174" /> format="default"/> when, and only when, they appear in all capitals, as shown here.
</t>

      <t>"ECDSA" and "ECDH" refer to the use of the Elliptic Curve Digital Signature Algorithm (ECDSA) and Elliptic Curve Diffie Hellman (ECDH), respectively. ECDSA and ECDH are used with the NIST P-384 curve (which is based on a 384-bit prime modulus) and the SHA-384 hash function.  Similarly, "RSA" and "DH" refer to Rivest-Shamir-Adleman (RSA) and Finite Field Diffie-Hellman (DH), respectively. RSA and DH are used with a 3072-bit or 4096-bit modulus.  When RSA is used for digital signature, it is used with the SHA-384 hash function.
</t>
      <t>Henceforth, this document refers to TLS versions 1.2 and 1.3 and DTLS versions 1.2 and 1.3 collectively as (D)TLS. "(D)TLS".
</t>
    </section>  <!-- terms -->

<section anchor="cnsa-suite" title="CNSA Suite"> numbered="true" toc="default">
      <name>CNSA Suites</name>
      <t><xref target="CNSA" /> format="default"/> approves the use of both finite field Finite Field and elliptic curve versions of the DH key agreement algorithm, algorithm as well as RSA-based key establishment. <xref target="CNSA" /> format="default"/> also approves certain versions of the RSA and elliptic curve digital signature algorithms. The approved encryption techniques include the Advanced Encryption Standard (AES) used with a 256-bit key in an Authenticated Encryption with Associated Data (AEAD) mode.
</t>
      <t>In particular, CNSA includes the following:

<list style="empty">
  <t>Encryption:
  <list style="empty">
    <t>AES

</t>

<dl newline="true">

<dt>Encryption:
</dt>
<dd>AES <xref target="AES" /> format="default"/> (with key size 256 bits),
operating in Galois/Counter Mode (GCM) <xref target="GCM" /></t>
    </list>
  </t>
  <t>Digital format="default"/>
</dd>

<dt>Digital Signature:
  <list style="empty">
    <t>ECDSA
</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>
  </t>
  <t>Key

</dd>

<dt>Key Establishment (includes key agreement and key transport):
  <list style="empty">
</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>
    </list>
  </t>
</list>
</t>
</dd>

</dl>

<t><xref target="CNSA" /> format="default"/> also approves the use of SHA-384 <xref target="SHS" /> for format="default"/> as the hash algorithm for mask generation, signature generation, Pseudo Random Pseudorandom Function (PRF) in TLS 1.2 and HMAC-based key derivation function Key Derivation Function (HKDF) in TLS 1.3.
</t>

      <section anchor="tls-ke" title="CNSA numbered="true" toc="default">
        <name>CNSA (D)TLS Key Establishment Algorithms"> Algorithms</name>
        <t>The following combination of algorithms and key sizes are used in CNSA (D)TLS:

<list style="empty">
  <t>AES

</t>
        <ul empty="true" spacing="normal">
          <li>AES with 256-bit key, operating in GCM mode</t>
  <t>ECDH 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" />)</t>
  <t>TLS format="default"/>)</li>
          <li>TLS PRF/HKDF with SHA-384 <xref target="SHS" /></t>
</list>
</t> format="default"/></li>
        </ul>
        <t>Or

<list style="empty">
  <t>AES

</t>
        <ul empty="true" spacing="normal">
          <li>AES with 256-bit key, operating in GCM mode</t>
  <t>RSA mode</li>
          <li>RSA key transport using 3072-bit or 4096-bit modulus <xref target="PWKE-B" /><xref format="default"/><xref target="RFC8017" /></t>
  <t>TLS format="default"/></li>
          <li>TLS PRF/HKDF with SHA-384 <xref target="SHS" /></t>
</list>
</t> format="default"/></li>
        </ul>
        <t>Or

<list style="empty">
  <t>AES

</t>
        <ul empty="true" spacing="normal">
          <li>AES with 256-bit key, operating in GCM mode</t>
  <t>DH mode</li>
          <li>DH using dhEphem with domain parameters specified below in <xref target="ff-groups"/> target="ff-groups" format="default"/> (see Section 6.1.2.1 in <xref target="PWKE-A" />)</t>
  <t>TLS format="default"/>)</li>
          <li>TLS PRF/HKDF with SHA-384 <xref target="SHS" /></t>
  </list>
</t> format="default"/></li>
        </ul>
        <t>The specific CNSA compliant CNSA-compliant cipher suites are listed in Section 5. <xref target="compliance"/>.
</t>
      </section>  <!-- tls-ke -->

<section anchor="tls-auth" title="CNSA numbered="true" toc="default">
        <name>CNSA TLS Authentication"> Authentication</name>
        <t>For server and/or client authentication, CNSA (D)TLS MUST <bcp14>MUST</bcp14> generate and verify either ECDSA signatures or RSA signatures.
</t>
        <t>In all cases, the client MUST <bcp14>MUST</bcp14> authenticate the
        server.  The server MAY <bcp14>MAY</bcp14> also authenticate the client, as
        needed by the specific application.
</t>
        <t>The public keys used to verify these signatures MUST <bcp14>MUST</bcp14>
        be contained in a certificate, see Section 5.4 certificate (see <xref target="certs"/> for more information.</t>
        information).</t>
      </section>  <!-- tls-auth -->

</section>  <!-- cnsa-suite -->

<section anchor="compliance" title="CNSA numbered="true" toc="default">
      <name>CNSA Compliance and Interoperability Requirements"> Requirements</name>
      <t>CNSA (D)TLS MUST NOT <bcp14>MUST NOT</bcp14> use TLS versions prior to (D)TLS
      1.2 in a CNSA compliant CNSA-compliant system.  CNSA (D)TLS servers and clients MUST
      <bcp14>MUST</bcp14> implement and use either (D)TLS version 1.2 <xref
      target="RFC5246" /><xref format="default"/> <xref target="RFC6347" />
      format="default"/> or (D)TLS version 1.3 <xref target="RFC8446" /><xref target="ID.dtls13" />.
      format="default"/> <xref target="RFC9147" format="default"/>.
</t>
      <section anchor="ecc-curves" title="Acceptable ECC Curves"> numbered="true" toc="default">
        <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>

<figure><artwork align="left">
      Curve    NIST name   SECG name
      --------------------------------
      P-384    nistp384    secp384r1
</artwork></figure>

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

  </tbody>
</table>

        <t><xref target="RFC8422" /> format="default"/> defines a variety of elliptic curves.  CNSA (D)TLS connections MUST <bcp14>MUST</bcp14> use secp384r1 (also called nistp384) nistp384), and the uncompressed form MUST <bcp14>MUST</bcp14> be used, as required by <xref target="RFC8422" /> format="default"/> and <xref target="RFC8446" />. format="default"/>.
</t>
        <t>Key pairs MUST <bcp14>MUST</bcp14> be generated following Section 5.6.1.2 of <xref target="PWKE-A" />. format="default"/>.
</t>
      </section>  <!-- ecc-curves -->

<section anchor="rsa-schemes" title="Acceptable numbered="true" toc="default">
        <name>Acceptable RSA Schemes, Parameters Parameters, and Checks"> Checks</name>
        <t><xref target="CNSA" /> format="default"/> specifies a minimum modulus size of 3072 bits; however, only two modulus sizes (3072 bits and 4096 bits) are supported by this profile.
</t>

<t>
<list style="empty">
  <t>For (D)TLS 1.2:</t>
  <t>
  <list style="empty">
    <t>For

<dl newline="true">

<dt>For (D)TLS 1.2:
</dt>
<dd><t>For certificate signature, RSASSA-PKCS1-v1.5 signatures, RSASSA-PKCS1-v1_5 <xref target="RFC8017" /> MUST
format="default"/> <bcp14>MUST</bcp14> be supported, and RSASSA-PSS <xref target="DSS" /> SHOULD
format="default"/> <bcp14>SHOULD</bcp14> be supported.</t>

              <t>For signatures in TLS handshake messages RSASSA-PKCS1-v1.5 messages, RSASSA-PKCS1-v1_5 <xref
target="RFC8017" /> MUST format="default"/> <bcp14>MUST</bcp14> be supported, and RSASSA-PSS <xref
target="DSS" /> SHOULD format="default"/> <bcp14>SHOULD</bcp14> be supported.</t>
              <t>For key transport, RSAES-PKCS1-v1.5 RSAES-PKCS1-v1_5 <xref target="RFC8017" /> MUST
format="default"/> <bcp14>MUST</bcp14> be supported.</t>
    </list>
    </t>
  <t>For
</dd>

<dt>For (D)TLS 1.3:</t>
  <t>
  <list style="empty">
    <t>For 1.3:
</dt>
<dd><t>For certificate signature, RSASSA-PKCS1-v1.5 signatures, RSASSA-PKCS1-v1_5 <xref target="RFC8017" /> MUST
format="default"/> <bcp14>MUST</bcp14> be supported, and RSASSA-PSS <xref
target="DSS" /> SHOULD format="default"/> <bcp14>SHOULD</bcp14> be supported.</t>
              <t>For signatures in TLS handshake messages messages, RSASSA-PSS <xref
              target="DSS" /> MUST format="default"/> <bcp14>MUST</bcp14> be
              supported.</t>
              <t>For key transport, TLS 1.3 does not support RSA key
              transport.</t>
    </list>
    </t>
  <t>For
</dd>

<dt>For all versions of (D)TLS:</t>
  <t>
  <list style="empty"> (D)TLS:
</dt>

<dd>
  <t>RSA exponent e MUST <bcp14>MUST</bcp14> satisfy 2^16&lt;e&lt;2^256
  2<sup>16</sup>&lt;e&lt;2<sup>256</sup> and be odd per <xref target="DSS" />.</t>
  format="default"/>.</t>
   <t>If RSASSA-PSS is supported (using rsa_pss_rsae_sha384 for example), then
   the implementation MUST <bcp14>MUST</bcp14> assert rsaEncryption as the public
   key algorithm, the hash algorithm (used for both mask generation and
   signature generation) MUST <bcp14>MUST</bcp14> be SHA-384, the mask generation
   function 1 (MGF1) from <xref target="RFC8017" /> MUST format="default"/>
   <bcp14>MUST</bcp14> be used, and the salt length MUST <bcp14>MUST</bcp14> be 48
   octets.</t>
    </list>
    </t>
  </list>
</t>
</dd>

</dl>

      </section>  <!-- rsa-schemes -->

<section anchor="ff-groups" title="Acceptable numbered="true" toc="default">
        <name>Acceptable Finite Field Groups"> Groups</name>
        <t><xref target="CNSA" /> format="default"/> specifies a minimum modulus size of 3072 bits; however, only two modulus sizes (3072 bits and 4096 bits) are supported by this profile.
</t>
        <t>Ephemeral key pairs MUST <bcp14>MUST</bcp14> be generated following Section 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 ephemeral key agreement.  The named groups are:

<list style="empty">
  <t>ffdhe3072 (ID=257)</t>
  <t>ffdhe4096 (ID=258)</t>
  </list>

</t>
        <ul empty="true" spacing="normal">
          <li>ffdhe3072 (ID=257)</li>
          <li>ffdhe4096 (ID=258)</li>
        </ul>
      </section>  <!-- ff-groups -->

<section anchor="certs" title="Certificates"> numbered="true" toc="default">
        <name>Certificates</name>
        <t>Certificates used to establish a CNSA (D)TLS connection MUST <bcp14>MUST</bcp14> be signed with ECDSA or RSA and MUST <bcp14>MUST</bcp14> be compliant with the "CNSA CNSA Suite Certificate and Certificate Revocation List (CRL) Profile" Profile <xref target="RFC8603" />. format="default"/>.
</t>
      </section>  <!-- certs -->

</section>  <!-- compliance -->

<section anchor="tls12-reqts" title="(D)TLS numbered="true" toc="default">
      <name>(D)TLS 1.2 Requirements"> 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 MUST <bcp14>MUST</bcp14> use <xref target="RFC5246" /> format="default"/> and SHOULD <bcp14>SHOULD</bcp14> implement the updates specified in <xref target="RFC8446" /> format="default"/> (outlined in Section 1.3). <xref sectionFormat="bare" section="1.3" target="RFC8446"/> of that document).
</t>
      <t>The CNSA (D)TLS 1.2 client MUST <bcp14>MUST</bcp14> offer at least one of these ciphersuites:

<list style="empty">
  <t>TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 cipher suites:

</t>
      <ul empty="true" spacing="normal">
        <li>TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 <xref target="RFC5289" /> format="default"/> <xref target="RFC8422" /></t>
  <t>TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 format="default"/></li>
        <li>TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 <xref target="RFC5289" /> format="default"/> <xref target="RFC8422" /></t>
  <t>TLS_RSA_WITH_AES_256_GCM_SHA384 format="default"/></li>
        <li>TLS_RSA_WITH_AES_256_GCM_SHA384 <xref target="RFC5288" /></t>
  <t>TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 format="default"/></li>
        <li>TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 <xref target="RFC5288" /> format="default"/> <xref target="RFC7919" /></t>
</list>
</t> format="default"/></li>
      </ul>
      <t>The CNSA cipher suites listed above MUST <bcp14>MUST</bcp14> be the first
      (most preferred) cipher suites in the ClientHello message.
</t>
      <t>A CNSA (D)TLS client that offers interoperability with servers that are not CNSA compliant MAY <bcp14>MAY</bcp14> offer additional cipher suites, but any additional cipher suites MUST <bcp14>MUST</bcp14> appear after the CNSA cipher suites in the ClientHello message.
</t>
      <t>A CNSA (D)TLS server MUST <bcp14>MUST</bcp14> accept one of the CNSA suites
      Suites above if they are offered in the ClientHello message before
      accepting a non-CNSA compliant non-CNSA-compliant suite.
</t>
      <t>If interoperability is not desired with non-CNSA compliant non-CNSA-compliant clients or
      servers, then the session MUST <bcp14>MUST</bcp14> fail if no CNSA suites Suites are
      offered or accepted.
</t>
      <section anchor="ext-master-secret" title="The extended_master_secret Extension"> numbered="true" toc="default">
        <name>The "extended_master_secret" Extension</name>
        <t>A CNSA (D)TLS client SHOULD <bcp14>SHOULD</bcp14> include and a CNSA
        (D)TLS server SHOULD <bcp14>SHOULD</bcp14> accept the
        "extended_master_secret" extension as specified in <xref
        target="RFC7627" />. format="default"/>. See Section 1 of <xref target="RFC7627" />
        sectionFormat="of" section="1" format="default"/> for security
        concerns when this extension is not used.
</t>
      </section>  <!-- ext-master-secret -->

<section anchor="tls12-sig-algs" title="The signature_algorithms Extension"> numbered="true" toc="default">
        <name>The "signature_algorithms" Extension</name>
        <t>A CNSA (D)TLS client MUST <bcp14>MUST</bcp14> include and a CNSA (D)TLS server MUST <bcp14>MUST</bcp14> also accept the "signature_algorithms" extension. The CNSA (D)TLS client MUST <bcp14>MUST</bcp14> offer and the
  CNSA (D)TLS server MUST <bcp14>MUST</bcp14> also accept at least one of the following values in the "signature_algorithms" extensions as specified in <xref target="RFC8446" />:

  <list style="empty">
    <t>ecdsa_secp384r1_sha384</t>
    <t>rsa_pkcs1_sha384</t>
    </list> format="default"/>:

        </t>
        <ul empty="true" spacing="normal">
          <li>ecdsa_secp384r1_sha384</li>
          <li>rsa_pkcs1_sha384</li>
        </ul>
        <t>And, if supported, the client SHOULD <bcp14>SHOULD</bcp14> offer and/or the server SHOULD <bcp14>SHOULD</bcp14> also accept:

  <list style="empty">
    <t>rsa_pss_pss_sha384</t>
    <t>rsa_pss_rsae_sha384</t>
    </list>

        </t>
        <ul empty="true" spacing="normal">
          <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 MUST <bcp14>MUST</bcp14> only accept ECDSA or RSA for signatures on ServerKeyExchange messages and for certification path validation.
</t>
        <t>Other client offerings MAY <bcp14>MAY</bcp14> be included to indicate the acceptable signature algorithms in cipher suites that are offered for interoperability with servers not compliant with CNSA and to indicate the signature algorithms that are acceptable for ServerKeyExchange messages and for certification path validation in non-compliant CNSA (D)TLS connections. These offerings MUST NOT <bcp14>MUST NOT</bcp14> be accepted by a CNSA compliant CNSA-compliant (D)TLS server.
</t>
      </section>  <!-- tls12-sig-algs -->

<section anchor="tls12-sig-algs-cert-ext" title="The signature_algorithms_cert Extension"> numbered="true" toc="default">
        <name>The "signature_algorithms_cert" Extension</name>
        <t>A CNSA (D)TLS client MAY <bcp14>MAY</bcp14> include the
        "signature_algorithms_cert" extension.  CNSA (D)TLS servers MUST
        <bcp14>MUST</bcp14> process the "signature_algorithms_cert" extension
        if it is offered per Section 4.2.3 of <xref target="RFC8446" />. sectionFormat="of"
        section="4.2.3" format="default"/>.
</t>
        <t>Both CNSA (D)TLS clients and servers MUST <bcp14>MUST</bcp14> use one of the following values for certificate path validation:

  <list>
    <t>ecdsa_secp384r1_sha384</t>
    <t>rsa_pkcs1_sha384</t>
    </list>

        </t>
        <ul empty="true" spacing="normal">
          <li>ecdsa_secp384r1_sha384</li>
          <li>rsa_pkcs1_sha384</li>
        </ul>
        <t>And, if supported, SHOULD <bcp14>SHOULD</bcp14> offer/accept:

  <list>
    <t>rsa_pss_pss_sha384</t>
    <t>rsa_pss_rsae_sha384</t>
    </list>

        </t>
        <ul empty="true" spacing="normal">
          <li>rsa_pss_pss_sha384</li>
          <li>rsa_pss_rsae_sha384</li>
        </ul>
      </section>  <!-- tls12-sig-algs-cert-ext -->

<section anchor="tls12-cert-request" title="The numbered="true" toc="default">
        <name>The CertificateRequest Message"> Message</name>
        <t>When a CNSA (D)TLS server is configured to authenticate the client, the server MUST <bcp14>MUST</bcp14> include the following values in its CertificateRequest.supported_signature_algorithms <xref target="RFC5246" /> format="default"/> offer:

  <list>
    <t>ecdsa_secp384r1_sha384</t>
    <t>rsa_pkcs1_sha384</t>
    </list>

        </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" />, SHOULD format="default"/>, <bcp14>SHOULD</bcp14> offer/accept:

  <list>
    <t>rsa_pss_pss_sha384</t>
    <t>rsa_pss_rsae_sha384</t>
    </list>

        </t>
        <ul empty="true" spacing="normal">
          <li>rsa_pss_pss_sha384</li>
          <li>rsa_pss_rsae_sha384</li>
        </ul>
      </section>  <!-- tls12-cert-request -->

<section anchor="tls12-cert-verify" title="The numbered="true" toc="default">
        <name>The CertificateVerify Message"> Message</name>
        <t>A CNSA (D)TLS client MUST <bcp14>MUST</bcp14> use ECDSA or RSA when sending the CertificateVerify message.  CNSA (D)TLS Servers MUST servers <bcp14>MUST</bcp14> only accept ECDSA or RSA in the CertificateVerify message.
</t>
      </section>  <!-- tls12-cert-verify -->

<section anchor="tls12-ske-message" title="The numbered="true" toc="default">
        <name>The Signature in the ServerKeyExchange Message"> Message</name>
        <t>A CNSA (D)TLS server MUST <bcp14>MUST</bcp14> sign the ServerKeyExchange message using ECDSA or RSA.
</t>
      </section>  <!-- tls12-ske-message" -->

<section anchor="tls12-cert-status" title="Certificate Status"> numbered="true" toc="default">
        <name>Certificate Status</name>
        <t>Certificate Authorities (CAs) providing certificates to a CNSA (D)TLS
        server or client MUST <bcp14>MUST</bcp14> provide certificate revocation
        status information via a Certificate Revocation List (CRL)
        distribution point or using the Online Certificate Status Protocol
        (OCSP).  A CNSA client SHOULD <bcp14>SHOULD</bcp14> request it according to
        <xref target="RFC8446" /> Section 4.4.2.1. format="default" sectionFormat="of"
        section="4.4.2.1"/>.  If OCSP is supported, the (D)TLS server SHOULD
        <bcp14>SHOULD</bcp14> provide OCSP responses in the "CertificateStatus"
        CertificateStatus message.
</t>
      </section>  <!-- tls12-cert-status -->

</section>  <!-- tls12-reqts -->

<section anchor="tls13-reqts" title="(D)TLS numbered="true" toc="default">
      <name>(D)TLS 1.3 Requirements"> Requirements</name>
      <t>The CNSA (D)TLS client MUST <bcp14>MUST</bcp14> offer the following CipherSuite cipher
      suite in the ClientHello:

<list style="empty">
  <t>TLS_AES_256_GCM_SHA384</t>
</list>

</t>
      <ul empty="true" spacing="normal">
        <li>TLS_AES_256_GCM_SHA384</li>
      </ul>

      <t>The CNSA (D)TLS client MUST <bcp14>MUST</bcp14> include at least one of
      the following values in "supported_groups":

<list style="empty">
  <t>ECDHE:  secp384r1</t>
  <t>DHE: ffdhe3072</t>
  <t>DHE: ffdhe4096</t>
</list> the "supported_groups" extension:

</t>
      <ul empty="true" spacing="normal">
        <li>ECDHE:  secp384r1</li>
        <li>DHE: ffdhe3072</li>
        <li>DHE: ffdhe4096</li>
      </ul>
      <t>The CNSA cipher suite MUST <bcp14>MUST</bcp14> be the first (most
      preferred) cipher suites suite in the ClientHello message and in the
      extensions.
</t>
      <t>A CNSA (D)TLS client that offers interoperability with servers that are
not CNSA compliant MAY <bcp14>MAY</bcp14> offer additional cipher suites, but any additional
cipher suites MUST <bcp14>MUST</bcp14> appear after the CNSA compliant CNSA-compliant cipher suites in the
ClientHello message.
</t>
      <t>A CNSA (D)TLS server MUST <bcp14>MUST</bcp14> accept one of the CNSA algorithms listed above if they are offered in the ClientHello message.
</t>
      <t>If interoperability is not desired with non-CNSA compliant non-CNSA-compliant clients or servers, then the session MUST <bcp14>MUST</bcp14> fail if no CNSA suites Suites are offered or accepted.
</t>
      <section anchor="tls13-sig-algs" title="The &quot;signature_algorithms&quot; Extension"> numbered="true" toc="default">
        <name>The "signature_algorithms" Extension</name>
        <t>A CNSA (D)TLS client MUST <bcp14>MUST</bcp14> include the "signature_algorithms" extension. The CNSA (D)TLS client MUST <bcp14>MUST</bcp14> offer at least one of the following values in the "signature_algorithms" extension:

  <list style="empty">
    <t>ecdsa_secp384r1_sha384</t>
    <t>rsa_pss_pss_sha384</t>
    <t>rsa_pss_rsae_sha384</t>
    </list>

        </t>
        <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 MAY <bcp14>MAY</bcp14> offer rsa_pkcs1_sha384 for use with TLS 1.2.  Other offerings MAY <bcp14>MAY</bcp14> be included to indicate the acceptable signature algorithms in cipher suites that are offered for interoperability with servers not compliant with CNSA in non-compliant CNSA (D)TLS connections.  These offerings MUST NOT <bcp14>MUST NOT</bcp14> be accepted by a CNSA compliant CNSA-compliant (D)TLS server.
</t>
      </section>  <!-- tls13-sig-algs -->

<section anchor="tls13-sig-algs-cert" title="The &quot;signature_algorithms_cert&quot; Extension"> numbered="true" toc="default">
        <name>The "signature_algorithms_cert" Extension</name>
        <t>A CNSA (D)TLS client SHOULD <bcp14>SHOULD</bcp14> include the "signature_algorithms_cert" extension. And And, if offered, the CNSA (D)TLS client MUST <bcp14>MUST</bcp14> offer at least one of the following values in the "signature_algorithms_cert" extension:

<list style="empty">
  <t>ecdsa_secp384r1_sha384</t>
  <t>rsa_pkcs1_sha384</t>
</list>

</t>
        <ul empty="true" spacing="normal">
          <li>ecdsa_secp384r1_sha384</li>
          <li>rsa_pkcs1_sha384</li>
        </ul>
        <t>And, if supported, SHOULD <bcp14>SHOULD</bcp14> offer:
<list style="empty">
  <t>rsa_pss_pss_sha384</t>
  <t>rsa_pss_rsae_sha384</t>
</list>
</t>
        <ul empty="true" spacing="normal">
          <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 MUST <bcp14>MUST</bcp14> only accept ECDSA or RSA for certificate path validation.
</t>
        <t>Other offerings MAY <bcp14>MAY</bcp14> be included to indicate the signature algorithms that are acceptable for certification path validation in non-compliant CNSA (D)TLS connections. These offerings MUST NOT <bcp14>MUST NOT</bcp14> be accepted by a CNSA compliant CNSA-compliant (D)TLS server.
</t>
      </section>  <!-- tls13-sig-algs-cert -->

<section anchor="tls13-early-data" title="The &quot;early_data&quot; Extension"> numbered="true" toc="default">
        <name>The "early_data" Extension</name>
        <t>A CNSA (D)TLS client or server MUST NOT <bcp14>MUST NOT</bcp14> include the
        "early_data" extension.  See Section 2.3 <xref target="RFC8446"
        format="default" sectionFormat="of" section="2.3" /> for security concerns.
</t>
      </section>  <!-- tls13-early-data -->

<section anchor="tls13-resumption" title="Resumption"> numbered="true" toc="default">
        <name>Resumption</name>
        <t>A CNSA (D)TLS server MAY <bcp14>MAY</bcp14> send a CNSA (D)TLS client a
        NewSessionTicket message to enable resumption. A CNSA (D)TLS client MUST
        <bcp14>MUST</bcp14> request "psk_dhe_ke" via the psk_key_exchange_modes
        "psk_key_exchange_modes" ClientHello extension to resume a session. A
        CNSA (D)TLS client MUST <bcp14>MUST</bcp14> offer ECDHE Ephemeral Elliptic Curve
        Diffie-Hellman (ECDHE) with SHA-384 and/or DHE Ephemeral Diffie-Hellman (DHE) with SHA-384 in the
        "supported_groups" and/or "key_share" extensions.
</t>
      </section>  <!-- tls13-resumption -->

<section anchor="tls13-cert-stat" title="Certificate Status"> numbered="true" toc="default">
        <name>Certificate Status</name>
        <t>Certificate Authorities (CAs) providing certificates to a CNSA (D)TLS server or client MUST <bcp14>MUST</bcp14> provide certificate revocation status information via a Certificate Revocation List (CRL) distribution point or using the Online Certificate Status Protocol (OCSP).  A CNSA client SHOULD <bcp14>SHOULD</bcp14> request it according to <xref target="RFC8446" /> Section 4.4.2.1. format="default" sectionFormat="of" section="4.4.2.1"/>.  If OCSP is supported, the (D)TLS server SHOULD <bcp14>SHOULD</bcp14> provide OCSP responses in the "CertificateEntry".
</t>
      </section>  <!-- tls13-cert-stat -->

</section>  <!-- tls13-reqts -->

<section anchor="sec-considerations" title="Security Considerations"> numbered="true" toc="default">
      <name>Security Considerations</name>
      <t>Most of the security considerations for this document are described
      in <xref target="RFC5246" />, format="default"/>, <xref target="RFC8446" />,
      format="default"/>, <xref target="RFC6347" />, format="default"/>, and <xref target="ID.dtls13" />.
      target="RFC9147" format="default"/>.  In addition, the security consideration
      considerations for ECC 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>In order to meet the goal of a consistent security level for the entire cipher suite, CNSA (D)TLS implementations MUST <bcp14>MUST</bcp14> only use the Elliptic Curves, elliptic curves, RSA schemes schemes, and Finite Fields defined in <xref target="ecc-curves" />, format="default"/>, <xref target="rsa-schemes" />, format="default"/>, and <xref target="ff-groups" /> format="default"/>, respectively.  If this is not the case, then security may be weaker than is required.
</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 reason, this profile forbids the use of early data.
</t>
    </section>  <!-- sec-considerations -->

<section anchor="iana-considerations" title="IANA Considerations"> numbered="true" toc="default">
      <name>IANA Considerations</name>
      <t>This document has no IANA actions.</t>
    </section> <!-- iana-considerations -->

</middle>
  <back>       <!--  ===== BACK MATTER ===== -->

   <references title="Normative References">

   <references>
      <name>References</name>
      <references>
        <name>Normative References</name>

        <reference anchor="AES" target="https://nvlpubs.nist.gov/nistpubs/fips/NIST.FIPS.197.pdf">
          <front>
  <title>Specification for
            <title>Announcing the Advanced Encryption Standard ADVANCED ENCRYPTION STANDARD (AES)</title>
            <author>
              <organization>National Institute of Standards and Technology</organization>
            </author>
            <date month="November" year="2001" /> year="2001"/>
          </front>
          <seriesInfo name="FIPS" value="197"></seriesInfo> value="197"/>
          <seriesInfo name="DOI" value="10.6028/NIST.FIPS.197"/>
        </reference> <!-- AES -->

<reference anchor="CNSA" target="https://www.cnss.gov/CNSS/issuances/Policies.cfm">
          <front>
            <title>Use of Public Standards for Secure Information Sharing</title>
            <author>
              <organization>Committee for National Security Systems</organization>
            </author>
            <date month="October" year="2016"></date> year="2016"/>
          </front>
          <seriesInfo name="CNSSP" value="15" /> value="15"/>
        </reference>

<!-- CNSA  [DSS] The URL below is correct.  Also found https://csrc.nist.gov/publications/detail/fips/186/4/final -->

<reference anchor="DSS" target="http://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.186-4.pdf"> 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</organization>
            </author>
            <date month="July" year="2013" /> year="2013"/>
          </front>
          <seriesInfo name="NIST Federal Information Processing Standard" value="186-4" /> name="FIPS PUB" value="186-4"/>
<seriesInfo name="DOI" value="10.6028/NIST.FIPS.186-4"/>
        </reference>

<!-- DSS  [GCM] The URL below is correct.  Also found https://csrc.nist.gov/publications/detail/sp/800-38d/final -->

<reference anchor="GCM" target="https://nvlpubs.nist.gov/nistpubs/Legacy/SP/nistspecialpublication800-38d.pdf">
          <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>
            <author fullname="Morris Dworkin" initials="M" surname="Dworkin"/>
            <date month="November" year="2007" /> year="2007"/>
          </front>
          <seriesInfo name="NIST Special Publication" value="800-38D" /> value="800-38D"/>
	  <seriesInfo name="DOI" value="10.6028/NIST.SP.800-38D"/>
        </reference>

<!-- GCM [PWKE-A] The URL below is correct.  Also found https://csrc.nist.gov/publications/detail/sp/800-56a/rev-3/final -->

<reference anchor="PWKE-A" target="https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-56Ar3.pdf">
          <front>
            <title>Recommendation for Pair-Wise Key Establishment Schemes
            Using Discrete Logarithm Cryptography</title>
  <author>
    <organization>National Institute of Standards and Technology</organization>
  </author>
            <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" /> year="2018"/>
          </front>
          <seriesInfo name="NIST Special Publication" value="800-56A, value="800-56A Revision 3" /> 3"/>
	  <seriesInfo name="DOI" value="10.6028/NIST.SP.800-56Ar3"/>
        </reference>

<!-- PWKE-A [PWKE-B] The URL below is correct. Also found https://csrc.nist.gov/publications/detail/sp/800-56b/rev-2/final -->

<reference anchor="PWKE-B" target="https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-56Br2.pdf">
          <front>
            <title>Recommendation for Pair-Wise Key Establishment Schemes Using Integer Factorization Cryptography</title>
  <author>
    <organization>National Institute of Standards and Technology</organization>
  </author>
            <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" /> year="2019"/>
          </front>
          <seriesInfo name="NIST Special Publication" value="800-56B, value="800-56B Revision 2" /> 2"/>
<seriesInfo name="DOI" value="10.6028/NIST.SP.800-56Br2"/>
        </reference>

<!-- PWKE-B [SHS] The URL below is correct.  Also found
https://csrc.nist.gov/publications/detail/fips/180/4/final -->

<reference anchor="SHS" target="https://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.180-4.pdf">
          <front>
            <title>Secure Hash Standard (SHS)</title>
            <author>
              <organization>National Institute of Standards and Technology</organization> Technology (NIST)</organization>
            </author>
            <date month="August" year="2015" /> year="2015"/>
          </front>
	  <seriesInfo name="NIST Federal Information Processing Standard" value="180-4" /> name="DOI" value="10.6028/NIST.FIPS.180-4"/>
          <seriesInfo name="FIPS PUB" value="180-4"/>
        </reference>  <!-- SHS

	<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5246.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5288.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5289.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6347.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7627.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7919.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8017.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8422.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8446.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8603.xml"/>

<!--  [ID.dtls13] [I-D.ietf-tls-dtls13] companion document RFC 9147; in AUTH48 as of 8/11/21 -->

&rfc2119;
&rfc5246;
&rfc5288;
&rfc5289;
&rfc6347;
&rfc7627;
&rfc7919;
&rfc8017;
&rfc8174;
&rfc8422;
&rfc8446;
&rfc8603;

<reference anchor="ID.dtls13" target="https://datatracker.ietf.org/doc/draft-ietf-tls-dtls13/"> anchor='RFC9147'>
<front>
<title>The Datagram Transport Layer Security (DTLS) Protocol Version 1.3</title>

<author initials="E." surname="Rescorla" initials='E' surname='Rescorla' fullname='Eric Rescorla'>
    <organization />
</author>

<author initials="H." surname="Tschofenig" initials='H' surname='Tschofenig' fullname='Hannes Tschofenig'>
    <organization />
</author>

<author initials="N." surname="Modadugu" initials='N' surname='Modadugu' fullname='Nagendra Modadugu'>
    <organization />
</author>

<date month="May" year="2020" month='August' year='2021' />

</front>
<annotation>Work in progress.</annotation>
<seriesInfo name="RFC" value="9147"/>
<seriesInfo name="DOI" value="10.17487/RFC9147"/>
</reference>
</references>
       <references>
        <name>Informative References</name>

<!-- dtls13 [SP80059] The URL below is correct.  Also found https://csrc.nist.gov/publications/detail/sp/800-59/final -->

    </references>

    <references title="Informative References">

        <reference anchor="SP80059" target="https://nvlpubs.nist.gov/nistpubs/Legacy/SP/nistspecialpublication800-59.pdf">
          <front>
            <title>Guideline for Identifying an Information System as a
            National Security System</title>
    <author>
      <organization>National Institute of Standards and Technology</organization>
    </author>
            <author fullname="William Barker" initials="W" surname="Barker"/>
            <date month="August" year="2003" /> year="2003"/>
          </front>
<seriesInfo name="Special Publication 800" value="59" /> name="DOI" value="10.6028/NIST.SP.800-59"/>
          <seriesInfo name="NIST Special Publication" value="800-59"/>
        </reference> <!-- SP80059 -->

<reference anchor="SECG" target="http://www.secg.org/download/aid-784/sec2-v2.pdf"> target="https://www.secg.org/sec2-v2.pdf">
          <front>
            <title>SEC 2: Recommended Elliptic Curve Domain Parameters</title>
            <author fullname="Daniel Brown" initials="D." surname="Brown" /> surname="Brown"/>
            <date month="February" year="2010" /> year="2010"/>
          </front>
	  <seriesInfo name="Version" value="2.0"/>
        </reference>  <!-- SECG -->

    </references>
    </references>
  </back>       <!--  ===== END BACK MATTER ===== -->

</rfc>