<?xml version='1.0' encoding='utf-8'?> version="1.0" encoding="UTF-8"?>
<!DOCTYPE rfc [
  <!ENTITY nbsp    "&#160;">
  <!ENTITY zwsp   "&#8203;">
  <!ENTITY nbhy   "&#8209;">
  <!ENTITY wj     "&#8288;">
]>
<?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?>
<!-- generated by https://github.com/cabo/kramdown-rfc version 1.6.26 (Ruby 3.0.2) -->

<rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft-ietf-ace-extend-dtls-authorize-07" number="9430" submissionType="IETF" category="std" consensus="true" submissionType="IETF" updates="9202" obsoletes="" tocDepth="2" tocInclude="true" sortRefs="true" symRefs="true" xml:lang="en" version="3">

  <!-- xml2rfc v2v3 conversion 3.16.0 -->
  <front>
    <title abbrev="CoAP-DTLS Extension to TLS">Extension of the Datagram Transport Layer Security (DTLS) Profile for Authentication and Authorization for Constrained Environments (ACE) to Transport Layer Security (TLS)</title>
    <seriesInfo name="Internet-Draft" value="draft-ietf-ace-extend-dtls-authorize-07"/> name="RFC" value="9430"/>
    <author initials="O." surname="Bergmann" fullname="Olaf Bergmann">
      <organization abbrev="TZI">Universität Bremen TZI</organization>
      <address>
        <postal>
          <street>Bremen, D-28359</street>
          <city>Bremen</city>
          <code>D-28359</code>
          <country>Germany</country>
        </postal>
        <email>bergmann@tzi.org</email>
      </address>
    </author>
    <author initials="J" surname="Preuß Mattsson" fullname="John Preuß Mattsson">
      <organization abbrev="Ericsson">Ericsson AB</organization>
      <address>
        <postal>
          <street>SE-164 80 Stockholm</street>
          <city>Stockholm</city>
          <code>164 80</code>
          <country>Sweden</country>
        </postal>
        <email>john.mattsson@ericsson.com</email>
      </address>
    </author>
    <author initials="G." surname="Selander" fullname="Göran Selander">
      <organization abbrev="Ericsson">Ericsson AB</organization>
      <address>
        <postal>
          <street>SE-164 80 Stockholm</street>
          <city>Stockholm</city>
          <code>164 80</code>
          <country>Sweden</country>
        </postal>
        <email>goran.selander@ericsson.com</email>
      </address>
    </author>
    <date year="2023" month="March" day="09"/>
    <workgroup>ACE Working Group</workgroup> month="July" year="2023"/>
    <area>sec</area>
    <workgroup>ace</workgroup>

    <keyword>Internet of Things (IoT)</keyword>
    <keyword>Internet of Things</keyword>
    <keyword>IOT</keyword>
    <keyword>OAuth</keyword>
    <keyword>Access Token</keyword>

    <abstract>
      <t>This document updates the Datagram "Datagram Transport Layer Security (DTLS) Profile for Authentication and Authorization for Constrained Environments (ACE) specified in RFC 9202 (ACE)" (RFC 9202) by specifying that the profile applies to Transport Layer Security (TLS) TLS as well as Datagram TLS (DTLS).</t> DTLS.</t>
    </abstract>
  </front>
  <middle>
    <section anchor="introduction">
      <name>Introduction</name>
      <t>The Authentication and Authorization for Constrained Environments (ACE) framework <xref target="RFC9200"/> defines an architecture for lightweight authentication between the Client, Resource Server (RS), and Authorization Server (AS) (AS), where the Client and RS may be constrained. The Datagram

      "Datagram Transport Layer Security (DTLS) Profile for Authentication and Authorization for Constrained Environments (ACE) (ACE)" <xref target="RFC9202"/> only specifies the use of Datagram Transport Layer Security (DTLS) DTLS <xref target="RFC9147"/> for transport-layer transport layer security between the nodes in the ACE architecture but works equally well for Transport Layer Security (TLS) <xref target="RFC8446"/>. For many constrained implementations, the Constrained Application Protocol (CoAP) over UDP <xref target="RFC7252"/> is the first choice, but when deploying ACE in networks controlled by other entities (such as the Internet), UDP might be blocked on the path between the Client and the Resource
Server, and the Client might have to fall back to CoAP over TCP <xref target="RFC8323"/> for NAT or firewall traversal. This dual support for security over TCP as well as UDP is already supported by the Object Security for Constrained RESTful Environments (OSCORE) profile <xref target="RFC9203"/>.</t>
      <t>This document updates <xref target="RFC9202"/> by specifying that the profile applies to TLS as well as DTLS. It only impacts the transport layer security channel between the Client and Resource Server. The same access rights are valid in case transport layer security is provided by either DTLS or TLS. The same access token can be used by either DTLS or TLS between a given (Client, RS) pair. Therefore, the value <tt>coap_dtls</tt> in the <tt>ace_profile</tt> parameter of an Authorization Server to Client (AS-to-Client) response or in the <tt>ace_profile</tt> claim of an access token indicates that either DTLS or TLS can be used for transport layer security.</t>
    </section>
    <section anchor="terminology">
      <name>Terminology</name>
      <t>The
        <t>
    The key words "<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 "<bcp14>OPTIONAL</bcp14>" in this document are to be interpreted as
    described in BCP 14 BCP&nbsp;14 <xref target="RFC2119"/> <xref target="RFC8174"/>
    when, and only when, they appear in all capitals, as shown here.</t> here.
        </t>
      <t>Readers are expected to be familiar with the terms and concepts
described in <xref target="RFC9200"/> and <xref target="RFC9202"/>.</t>
    </section>
    <section anchor="specific-changes-to-rfc-9202">
      <name>Specific Changes to RFC 9202</name>
      <t>The main changes to <xref target="RFC9202"/> specified in this document are limited
to replacing "DTLS" with "DTLS/TLS" throughout the document. This
essentially impacts the use of secure transport transport, as described in the
sections 3.2.2, 3.3.2, 4,
Sections <xref target="RFC9202" section="3.2.2" sectionFormat="bare"/>, <xref target="RFC9202" section="3.3.2" sectionFormat="bare"/>, <xref target="RFC9202" section="4" sectionFormat="bare"/>, and 5.</t> <xref target="RFC9202" section="5" sectionFormat="bare"/>.</t>
      <t>In addition to this, the Client and Resource Server behavior is
updated to describe the case where either or both DTLS and TLS may be
available, as described in the following section.</t>
    </section>
    <section anchor="connection-establishment">
      <name>Connection Establishment</name>
      <t>Following the procedures defined in <xref target="RFC9202"/>, a
Client can retrieve an Access Token access token from an Authorization Server in
order to establish a security association with a specific Resource
Server. The <tt>ace_profile</tt> parameter in the Client-to-AS request and
AS-to-client
AS-to-Client response is used to determine the ACE profile that the
Client uses towards the Resource Server.</t>
      <t>The <tt>ace_profile</tt> parameter indicates the use of the DTLS
profile for ACE ACE, as defined in <xref target="RFC9202"/>. Therefore, the Client typically
first tries using DTLS to connect to the Resource Server. If this fails fails, the
Client <bcp14>MAY</bcp14> try to connect to the Resource Server via TLS.</t>
      <t>As resource-constrained devices are not expected to support both
transport layer security mechanisms, Clients and Resource Servers
<bcp14>SHOULD</bcp14> support DTLS and <bcp14>MAY</bcp14> support TLS. A Client that implements either
TLS or DTLS but not both might fail in establishing a secure
communication channel with the Resource Server altogether. Non-constrained Nonconstrained
Clients and Resource Servers <bcp14>SHOULD</bcp14> support both TLS and DTLS.</t>
      <t>Note that a communication setup with an a priori unknown Resource
Server typically employs an initial unauthorized resource request request, as
illustrated in Section 2 of <xref target="RFC9202"/>. target="RFC9202" section="2" sectionFormat="of"/>. If this
message exchange succeeds, the Client <bcp14>SHOULD</bcp14> first use the same
underlying transport protocol also for the establishment of the security
association to the Resource Server (i.e., DTLS for UDP, and TLS for TCP).</t>
      <t>As a consequence, the selection of the transport protocol used for the
initial unauthorized resource request also depends on the transport
layer security mechanism supported by the Client.  Clients that
support either DTLS or TLS but not both <bcp14>SHOULD</bcp14> use the transport
protocol underlying the supported transport layer security mechanism
also
for an initial unauthorized resource request to the Resource
Server
Server, as in Section 2 of <xref target="RFC9202"/>.</t> target="RFC9202" section="2" sectionFormat="of"/>.</t>
    </section>
    <section anchor="iana-considerations">
      <name>IANA Considerations</name>
      <t>The following updates have been done to
      <t>In the "ACE Profiles" registry
for the profile with a "CBOR Value" field value of 1 and "Name" of "coap_dtls":</t>
      <t>Note to RFC Editor: Please replace all occurrences of "[RFC-XXXX]" with registry, the RFC number of this specification Description and delete this paragraph.</t>
      <t>Description: Profile Reference fields
   have been updated as follows for coap_dtls:</t>
      <dl newline="false" spacing="normal">
	<dt>Name:</dt><dd>coap_dtls</dd>
	<dt>Description:</dt> <dd>Profile for delegating client Authentication and
Authorization for Constrained Environments by establishing a Datagram
Transport Layer Security (DTLS) or Transport Layer Security (TLS)
channel between resource-constrained nodes.</t>
      <t>Change Controller:  IESG</t>
      <t>Reference:  [RFC9202] [RFC-XXXX]</t> nodes.</dd>
      <dt>CBOR Value:</dt> <dd>1</dd>
      <dt>Reference:</dt>  <dd><xref target="RFC9202"/>, RFC 9430</dd>
      </dl>
    </section>
    <section anchor="security-considerations">
      <name>Security Considerations</name>
      <t>The security consideration and requirements in <xref target="RFC9202"/>, TLS 1.3 <xref target="RFC8446"/>, and BCP 195 <xref target="RFC8996"/> <xref target="RFC9325"/> also apply to this document.</t>
    </section>
  </middle>
  <back>
    <references>
      <name>References</name>
      <references>
        <name>Normative References</name>
        <reference anchor="RFC7252" target="https://www.rfc-editor.org/info/rfc7252" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7252.xml">
          <front>
            <title>The Constrained Application Protocol (CoAP)</title>
            <author fullname="Z. Shelby" initials="Z." surname="Shelby"/>
            <author fullname="K. Hartke" initials="K." surname="Hartke"/>
            <author fullname="C. Bormann" initials="C." surname="Bormann"/>
            <date month="June" year="2014"/>
            <abstract>
              <t>The Constrained Application Protocol (CoAP) is a specialized web transfer protocol for use with constrained nodes and constrained (e.g., low-power, lossy) networks. The nodes often have 8-bit microcontrollers with small amounts of ROM and RAM, while constrained networks such as IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs) often have high packet error rates and a typical throughput of 10s of kbit/s. The protocol is designed for machine- to-machine (M2M) applications such as smart energy and building automation.</t>
              <t>CoAP provides a request/response interaction model between application endpoints, supports built-in discovery of services and resources, and includes key concepts of the Web such as URIs and Internet media types. CoAP is designed to easily interface with HTTP for integration with the Web while meeting specialized requirements such as multicast support, very low overhead, and simplicity for constrained environments.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="7252"/>
          <seriesInfo name="DOI" value="10.17487/RFC7252"/>
        </reference>
        <reference anchor="RFC8323" target="https://www.rfc-editor.org/info/rfc8323" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8323.xml">
          <front>
            <title>CoAP (Constrained Application Protocol) over TCP, TLS, and WebSockets</title>
            <author fullname="C. Bormann" initials="C." surname="Bormann"/>
            <author fullname="S. Lemay" initials="S." surname="Lemay"/>
            <author fullname="H. Tschofenig" initials="H." surname="Tschofenig"/>
            <author fullname="K. Hartke" initials="K." surname="Hartke"/>
            <author fullname="B. Silverajan" initials="B." surname="Silverajan"/>
            <author fullname="B. Raymor" initials="B." role="editor" surname="Raymor"/>
            <date month="February" year="2018"/>
            <abstract>
              <t>The Constrained Application Protocol (CoAP), although inspired by HTTP, was designed to use UDP instead of TCP. The message layer of CoAP over UDP includes support for reliable delivery, simple congestion control, and flow control.</t>
              <t>Some environments benefit from the availability of CoAP carried over reliable transports such as TCP or Transport Layer Security (TLS). This document outlines the changes required to use CoAP over TCP, TLS, and WebSockets transports. It also formally updates RFC 7641 for use with these transports and RFC 7959 to enable the use of larger messages over a reliable transport.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="8323"/>
          <seriesInfo name="DOI" value="10.17487/RFC8323"/>
        </reference>
        <reference anchor="RFC8446" target="https://www.rfc-editor.org/info/rfc8446" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8446.xml">
          <front>
            <title>The Transport Layer Security (TLS) Protocol Version 1.3</title>
            <author fullname="E. Rescorla" initials="E." surname="Rescorla"/>
            <date month="August" year="2018"/>
            <abstract>
              <t>This document specifies version 1.3 of the Transport Layer Security (TLS) protocol. TLS allows client/server applications to communicate over the Internet in a way that is designed to prevent eavesdropping, tampering, and message forgery.</t>
              <t>This document updates RFCs 5705 and 6066, and obsoletes RFCs 5077, 5246, and 6961. This document also specifies new requirements for TLS 1.2 implementations.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="8446"/>
          <seriesInfo name="DOI" value="10.17487/RFC8446"/>
        </reference>
        <reference anchor="RFC9147" target="https://www.rfc-editor.org/info/rfc9147" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9147.xml">
          <front>
            <title>The Datagram Transport Layer Security (DTLS) Protocol Version 1.3</title>
            <author fullname="E. Rescorla" initials="E." surname="Rescorla"/>
            <author fullname="H. Tschofenig" initials="H." surname="Tschofenig"/>
            <author fullname="N. Modadugu" initials="N." surname="Modadugu"/>
            <date month="April" year="2022"/>
            <abstract>
              <t>This document specifies version 1.3 of the Datagram Transport Layer Security (DTLS) protocol. DTLS 1.3 allows client/server applications to communicate over the Internet in a way that is designed to prevent eavesdropping, tampering, and message forgery.</t>
              <t>The DTLS 1.3 protocol is based on the Transport Layer Security (TLS) 1.3 protocol and provides equivalent security guarantees with the exception of order protection / non-replayability. Datagram semantics of the underlying transport are preserved by the DTLS protocol.</t>
              <t>This document obsoletes RFC 6347.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="9147"/>
          <seriesInfo name="DOI" value="10.17487/RFC9147"/>
        </reference>
        <reference anchor="RFC9200" target="https://www.rfc-editor.org/info/rfc9200" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9200.xml">
          <front>
            <title>Authentication and Authorization for Constrained Environments Using the OAuth 2.0 Framework (ACE-OAuth)</title>
            <author fullname="L. Seitz" initials="L." surname="Seitz"/>
            <author fullname="G. Selander" initials="G." surname="Selander"/>
            <author fullname="E. Wahlstroem" initials="E." surname="Wahlstroem"/>
            <author fullname="S. Erdtman" initials="S." surname="Erdtman"/>
            <author fullname="H. Tschofenig" initials="H." surname="Tschofenig"/>
            <date month="August" year="2022"/>
            <abstract>
              <t>This specification defines a framework for authentication and authorization in Internet of Things (IoT) environments called ACE-OAuth.  The framework is based on a set of building blocks including OAuth 2.0 and the Constrained Application Protocol (CoAP), thus transforming a well-known and widely used authorization solution into a form suitable for IoT devices.  Existing specifications are used where possible, but extensions are added and profiles are defined to better serve the IoT use cases.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="9200"/>
          <seriesInfo name="DOI" value="10.17487/RFC9200"/>
        </reference>
        <reference anchor="RFC9202" target="https://www.rfc-editor.org/info/rfc9202" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9202.xml">
          <front>
            <title>Datagram Transport Layer Security (DTLS) Profile for Authentication and Authorization for Constrained Environments (ACE)</title>
            <author fullname="S. Gerdes" initials="S." surname="Gerdes"/>
            <author fullname="O. Bergmann" initials="O." surname="Bergmann"/>
            <author fullname="C. Bormann" initials="C." surname="Bormann"/>
            <author fullname="G. Selander" initials="G." surname="Selander"/>
            <author fullname="L. Seitz" initials="L." surname="Seitz"/>
            <date month="August" year="2022"/>
            <abstract>
              <t>This specification defines a profile of the Authentication and Authorization for Constrained Environments (ACE) framework that allows constrained servers to delegate client authentication and authorization.  The protocol relies on DTLS version 1.2 or later for communication security between entities in a constrained network using either raw public keys or pre-shared keys.  A resource-constrained server can use this protocol to delegate management of authorization information to a trusted host with less-severe limitations regarding processing power and memory.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="9202"/>
          <seriesInfo name="DOI" value="10.17487/RFC9202"/>
        </reference>
        <reference anchor="RFC2119" target="https://www.rfc-editor.org/info/rfc2119" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml">
          <front>
            <title>Key words for use in RFCs to Indicate Requirement Levels</title>
            <author fullname="S. Bradner" initials="S." surname="Bradner"/>
            <date month="March" year="1997"/>
            <abstract>
              <t>In many standards track documents several words are used to signify the requirements in the specification.  These words are often capitalized.  This document defines these words as they should be interpreted in IETF documents.  This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.</t>
            </abstract>
          </front>
          <seriesInfo name="BCP" value="14"/>
          <seriesInfo name="RFC" value="2119"/>
          <seriesInfo name="DOI" value="10.17487/RFC2119"/>
        </reference>
        <reference anchor="RFC8174" target="https://www.rfc-editor.org/info/rfc8174" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml">
          <front>
            <title>Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words</title>
            <author fullname="B. Leiba" initials="B." surname="Leiba"/>
            <date month="May" year="2017"/>
            <abstract>
              <t>RFC 2119 specifies common key words that may be used in protocol specifications.  This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings.</t>
            </abstract>
          </front>
          <seriesInfo name="BCP" value="14"/>
          <seriesInfo name="RFC" value="8174"/>
          <seriesInfo name="DOI" value="10.17487/RFC8174"/>
        </reference>

<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7252.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8323.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8446.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9147.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9200.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9202.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml"/>

      </references>
      <references>
        <name>Informative References</name>
        <reference anchor="RFC8996" target="https://www.rfc-editor.org/info/rfc8996" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8996.xml">
          <front>
            <title>Deprecating TLS 1.0 and TLS 1.1</title>
            <author fullname="K. Moriarty" initials="K." surname="Moriarty"/>
            <author fullname="S. Farrell" initials="S." surname="Farrell"/>
            <date month="March" year="2021"/>
            <abstract>
              <t>This document formally deprecates Transport Layer Security (TLS) versions 1.0 (RFC 2246) and 1.1 (RFC 4346). Accordingly, those documents have been moved to Historic status. These versions lack support for current and recommended cryptographic algorithms and mechanisms, and various government and industry profiles of applications using TLS now mandate avoiding these old TLS versions. TLS version 1.2 became the recommended version for IETF protocols in 2008 (subsequently being obsoleted by TLS version 1.3 in 2018), providing sufficient time to transition away from older versions. Removing support for older versions from implementations reduces the attack surface, reduces opportunity for misconfiguration, and streamlines library and product maintenance.</t>
              <t>This document also deprecates Datagram TLS (DTLS) version 1.0 (RFC 4347) but not DTLS version 1.2, and there is no DTLS version 1.1.</t>
              <t>This document updates many RFCs that normatively refer to TLS version 1.0 or TLS version 1.1, as described herein. This document also updates the best practices for TLS usage in RFC 7525; hence, it is part of BCP 195.</t>
            </abstract>
          </front>
          <seriesInfo name="BCP" value="195"/>
          <seriesInfo name="RFC" value="8996"/>
          <seriesInfo name="DOI" value="10.17487/RFC8996"/>
        </reference>
        <reference anchor="RFC9203" target="https://www.rfc-editor.org/info/rfc9203" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9203.xml">
          <front>
            <title>The Object Security for Constrained RESTful Environments (OSCORE) Profile of the Authentication and Authorization for Constrained Environments (ACE) Framework</title>
            <author fullname="F. Palombini" initials="F." surname="Palombini"/>
            <author fullname="L. Seitz" initials="L." surname="Seitz"/>
            <author fullname="G. Selander" initials="G." surname="Selander"/>
            <author fullname="M. Gunnarsson" initials="M." surname="Gunnarsson"/>
            <date month="August" year="2022"/>
            <abstract>
              <t>This document specifies a profile for the Authentication and Authorization for Constrained Environments (ACE) framework.  It utilizes Object Security for Constrained RESTful Environments (OSCORE) to provide communication security and proof-of-possession for a key owned by the client and bound to an OAuth 2.0 access token.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="9203"/>
          <seriesInfo name="DOI" value="10.17487/RFC9203"/>
        </reference>
        <reference anchor="RFC9325" target="https://www.rfc-editor.org/info/rfc9325" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9325.xml">
          <front>
            <title>Recommendations for Secure Use of Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS)</title>
            <author fullname="Y. Sheffer" initials="Y." surname="Sheffer"/>
            <author fullname="P. Saint-Andre" initials="P." surname="Saint-Andre"/>
            <author fullname="T. Fossati" initials="T." surname="Fossati"/>
            <date month="November" year="2022"/>
            <abstract>
              <t>Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS) are used to protect data exchanged over a wide range of application protocols and can also form the basis for secure transport protocols. Over the years, the industry has witnessed several serious attacks on TLS and DTLS, including attacks on the most commonly used cipher suites and their modes of operation. This document provides the latest recommendations for ensuring the security of deployed services that use TLS and DTLS. These recommendations are applicable to the majority of use cases.</t>
              <t>RFC 7525, an earlier version of the TLS recommendations, was published when the industry was transitioning to TLS 1.2. Years later, this transition is largely complete, and TLS 1.3 is widely available. This document updates the guidance given the new environment and obsoletes RFC 7525. In addition, this document updates RFCs 5288 and 6066 in view of recent attacks.</t>
            </abstract>
          </front>
          <seriesInfo name="BCP" value="195"/>
          <seriesInfo name="RFC" value="9325"/>
          <seriesInfo name="DOI" value="10.17487/RFC9325"/>
        </reference>

<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8996.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9203.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9325.xml"/>

      </references>
    </references>
    <section numbered="false" anchor="acknowledgments">
      <name>Acknowledgments</name>
      <t>The authors would like to thank Marco Tiloca <contact fullname="Marco Tiloca"/> for reviewing this
specification.</t>
    </section>

  </back>
  <!-- ##markdown-source:
H4sIAAAAAAAAA8VY7XLbuBX9j6dAtTOdpCOpsewktqbtrGIrWe84tmspbbfZ
zAYiIQlrkuACoL3ajJ+l/dFn6AM0L9ZzAZCiZDtOZtpZ/7BIEB/3Hpx77gV6
vR5zymVyyMc/O1lYpQuu59wtJT8STiyMyPnUiMKW2jh+IlbS8IlMKqPcij86
mp5MHvNzo+cqk3yuDR9VGFo4lQhHU4ki9U3aqF9CC3U61IV1RqhCpnxcXCmj
ixyDLH80Ohw/5k5/YklakaU6KUQOo1Mj5q6npJv3RCJ7knxIe6nLbE/EZSUT
s5mRV0MsOzrvkcktX2mtk8mXTdjLhJPWsapM6WHIDwZPBkyVZsidqawbPHly
gAZAMOTWpexam8uF0VU55PCP/xWvqljwV9TEAIQU+ZAfj6cvGUt0ik9DXmH9
fVaqIf+KJ6LglZVcGCMAgJpzkWV8Je1jDiyXwi75UhrJOJxJhvQBjxbYGTm3
zfsqb7+iZypLtxzyAWPBsSHr8YDBWSbm/IU0i1wUBY2tTPjQatMGVr4p1JU0
VrmP/3L8hZHYRD79+zE+15CHN/JRAozQpcuPeoP93acH+JLoqnBmNeSvpMHM
KzTJXKhsyGdxra/dL6qP1RrrvtXLApST1cd/8NfCOWs1GaQK5ZTI4OG3bZNv
d/SWj41K6J2PXrSsrVtbJk/GvZ1ne3z/CZ8As8ulzvK22ZNrmcpibfWPMK6f
x8W+lnG+fqLzxv5XH/8NcoPRGYJDmraxrbb/q5ULDQv6Nq62aSZjhcZWOOzs
kGHIxcvD54Ong2F43N8d7NaPe3vP4uPBzt7z+hHkXz9iGFPFfHvC/YODZ+tO
9YQHu4On6EHq4VbUFv4m45OXQ955ix69v+HvXYexXq8HOEhDEsfYdKksRwRX
JCI8RuWvK2G2lImaK3xUBfnmJYLPVvHDiuLfLYXzVpZxcVGWmSLLH9I/Liy/
lhAB/K5dhK4Fb/oBoFylaSYZ+4ofgwY6rRJvPeEl/ydOzrGsJHHjHz7Erb+5
4amcY4DFlFCsZKmcTFxlArSZWizdtaT/XGxaMJP4AP04BASF6/ILaXVlEgnX
DUSGP7qYPO7eYWf9eQRYrkkHPaRhFt/9YsJz6OZMIh4ad/p8+mvSo8ZrALx0
ka0avgTaktojCX+2eWE6BCGmo9Vd3R+Zivrbun8NMi1S6BTLqfBCeWljt2aV
47S1lsufKuSbVSAczf4AN70xJA43N33+Ev1J19vYc5WXGSUC5/Gy3Q20RhQE
EVvADjnTGX9EqRvpjnb6zdF5WINkCQ6rgNlcGet4stQqkd1gPrYJbCwz7cON
XIS3BSDwfsEiREWWYU3EpcYchnvtoV14ZKtkSeFFUyN8pME48I8Wzz19wadZ
Bq3FcB0wLIVbbiDcIiG91oxmgbLd5kPsF+ZdiitJCjCnJD8TySW9kPvB++lh
9J6UOG736WhKlQAQkNc0ClBSWhYZsZykERuIJFP6PaMBDR+aKVuCQi5ikMhQ
l6SrelxAiaw9m/0Ijqx3fZvuF+PJdF5lW7Q/mxyeXYD5tdbVEQAf+vcpeDtK
vkA6oYNtfcR7nx+7EGegHlJG2NYmSvhWlCRL1B0y25KkICabqhRkxEIGuUgS
aS03tIlADyF0JTLl9T8R9hOrwXN4caXSALFUnom+TKVgI+u3F3H6Uha+Lpx5
sbhnYOOA4Atk3wJhVIsr4rQUKtiPulAbxAxhApsryd8nWpQ/UNH7vhaI96iG
f4hov8dYkn5EBckUzLhTkom3ATmIc8/pXnh7zI0EEAVpnLl7+iQTKo9Tb7is
ipS0wcskGHCHy21QNqRwC3aQDolxiqpTFTrTi1VIi5dyRbKXWt55/WYy7XTD
Lz89888X4z+/Ob4YH9Hz5JvRyUnzwGKPyTdnb06O1k/rkYdnr1+PT4/CYLTy
jSbWeT36rhM0oXN2Pj0+Ox2ddAI87dggYgFYuKhIlUojKTSFZRDzxKhZqDhe
HJ7/5587e4ig3yCEBjs7Bwih8LK/83wPLySOYTUfF+EVaK4YQkkKvzGkJYko
lUNZ3aVYskt9XfjDBuD73VtC5t2Q/2GWlDt7f4oN5PBGY43ZRqPH7HbLrcEB
xDua7limQXOjfQvpTXtH322817i3Ghm7gAxCTT3y8mdoEAEetmAucpUpgHUN
IgZNAaGshxXpJcEJa2tj2oUS9WpJXJ8IOQl1QMIPoUGLIGh1+RgYigq+8AoV
v7ZFcqPqvM2bTOXI7ynDKIO0KBKS0g5FTyd44J9/79/dEqfTxVJXQWfreUJG
YYhISpW+LmhLaixcfJC1JQ/c2YABfRk6+fTPd/uD/qCLn1362QusfAo4jkHB
NFUuntPJoe6t6m6rTJxJJFBFwmLj+dxvVr26H+71ONSKUUHQf4YKICgJTUu/
oWpk4gpnJjHLZPcuNyAyWaavCcnokN9HJMQivPKxdRit7JLwY+xl0z/mr0Sm
AMvGunmDJdhTLMqiuyRtCHejJCoEEt2gjFOvjHOj83uVWBUMmhYkWdbmICs0
OUjg+JeoMMYzQdRcSrbLlpCN7ksHql35kOaPJrD5pwqrEq4sJIIkONTkARDV
C7bfKOc1WTZlaZ3i65xfw4ERFADXgtS6XV/VuTnEy/2WrlNJQ1x/ZqT7oLJd
8FNtfN/+3Mqg0Tq3KjE94oOFwpS2jbykjfcsg69JIEng9m37+fE8BPEcBLRt
16FbmHD18Bz8SglfQjA2soS3/9hrF+OpvELFHOSt0G5D4uqakWKD3VvA5JLk
SNmcKnlvoL0rNC2Lyl3P2gQbuVM3+npn1KBIe94cF2wMVxbzvZ+AKn2y28dv
KKEJL9qmhuoEemS7ZInO86qojxh1rdco+DaCInN6IWnZPj/VRRs79ilv+Za3
3r7a46OwJ6faRV4LvmmWla4qYyhS/VYaaJriVXFZUAreisk127jM6bzjT9/x
RgyDmpvLtOHAOiotU1lWkU8usHsShWtAEbFB9UhIlkN3xILSYUhEcBJaJNNN
eY4ABP5TgLlYxrKKrp2yUMk3rCrrwx6qDR1qN/SXbfWsQ7SmHmvr1j0R8Ej1
Zb8buEKT4njTbSTeH2cPzx+H+BD+lEq4FEmMZiuziEZc+g5717UmIvQzQScX
cTSVBbQrHh+bmdl98XX7LBaQ7vMm7ohMrKbcXSeCdrTEDaq3Zm3A2rXWRhEa
zfoPiwFrtvGzqbi1gzW5hf0kK/0F1+h05A+hOEWZcKsQ1H+dnetDpT9fz+hU
lOpC1mt2SOTjLY/twKKFQkRAvCMN63wQk2Pn8MXZBf8LHZY6ILjM0nhygm07
oYY/BdE79N5pDlOdYR3yoagbo7bRZsjPM0kVSajJpC+7dQI8DfHQ+jk+fPgt
3YPe3IRKjXmcMEVR5bNwCvOZok7a66upFAT2IkPHTCS/hRHlEpgd+TqmpH7D
jestGrDAeEAW0/TtCy/2BRdedDLd1OH6Wos9dK314F0T2z6p35nh/EUXXA4l
NVka7n2APD8eT15RiT+XHmy0fP82Uuv7d7xB3Zfm9dJ38Wx9d9D+6HeA2K1M
TGDbxR3F5E5/t31pFtQJJzi+c/A0fjg4eOYPcPGWnA4PFF1067GqS+N1jR6u
f+nuiOweJZQzMpkuvAnswzCyRqZ/7BS6cxM8CIFpcfqtwOZMXcbYEMUlfy1M
ovlUZToRfrcNigYZi1jkgw3axeXnWTWfs/8Cun4WQGAcAAA=

-->
</rfc>