rfc9918.original.xml   rfc9918.xml 
<?xml version='1.0' encoding='utf-8'?> <?xml version='1.0' encoding='utf-8'?>
<!DOCTYPE rfc [ <!DOCTYPE rfc [
<!ENTITY nbsp "&#160;"> <!ENTITY nbsp "&#160;">
<!ENTITY zwsp "&#8203;"> <!ENTITY zwsp "&#8203;">
<!ENTITY nbhy "&#8209;"> <!ENTITY nbhy "&#8209;">
<!ENTITY wj "&#8288;"> <!ENTITY wj "&#8288;">
]> ]>
<?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?>
<!-- generated by https://github.com/cabo/kramdown-rfc version 1.7.5 (Ruby 3.2.2 <rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft
) --> -ietf-netconf-over-tls13-04" number="9918" category="std" consensus="true" submi
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft ssionType="IETF" updates="7589" obsoletes="" tocInclude="true" sortRefs="true" s
-ietf-netconf-over-tls13-04" category="std" consensus="true" submissionType="IET ymRefs="true" version="3" xml:lang="en">
F" updates="7589" tocInclude="true" sortRefs="true" symRefs="true" version="3">
<!-- xml2rfc v2v3 conversion 3.19.1 --> <front>
<front>
<title abbrev="NETCONF over TLS">Updates to Using the NETCONF Protocol over Transport Layer Security (TLS) with Mutual X.509 Authentication</title> <title abbrev="NETCONF over TLS">Updates to Using the NETCONF Protocol over Transport Layer Security (TLS) with Mutual X.509 Authentication</title>
<seriesInfo name="Internet-Draft" value="draft-ietf-netconf-over-tls13-04"/> <seriesInfo name="RFC" value="9918"/>
<author initials="S." surname="Turner" fullname="Sean Turner"> <author initials="S." surname="Turner" fullname="Sean Turner">
<organization>sn3rd</organization> <organization>sn3rd</organization>
<address> <address>
<email>sean@sn3rd.com</email> <email>sean@sn3rd.com</email>
</address> </address>
</author> </author>
<author initials="R." surname="Housley" fullname="Russ Housley"> <author initials="R." surname="Housley" fullname="Russ Housley">
<organization abbrev="Vigil Security">Vigil Security, LLC</organization> <organization abbrev="Vigil Security">Vigil Security, LLC</organization>
<address> <address>
<postal> <postal>
<street>516 Dranesville Road</street> <street>516 Dranesville Road</street>
<city>Herndon, VA</city> <city>Herndon</city>
<region>VA</region>
<code>20170</code> <code>20170</code>
<country>US</country> <country>United States of America</country>
</postal> </postal>
<email>housley@vigilsec.com</email> <email>housley@vigilsec.com</email>
</address> </address>
</author> </author>
<date year="2024" month="January" day="18"/> <date year="2026" month="January"/>
<area>Operations and Management</area>
<workgroup>Network Configuration</workgroup> <area>OPS</area>
<workgroup>netconf</workgroup>
<keyword>NETCONF</keyword> <keyword>NETCONF</keyword>
<keyword>TLS 1.3</keyword> <keyword>TLS 1.3</keyword>
<keyword>TLS 1.2</keyword> <keyword>TLS 1.2</keyword>
<keyword>Early Data</keyword> <keyword>Early Data</keyword>
<abstract> <abstract>
<?line 43?>
<t>RFC 7589 defines how to protect NETCONF messages with TLS 1.2. This <t>RFC 7589 defines how to protect Network Configuration Protocol (NETCONF) mess ages with TLS 1.2. This
document updates RFC 7589 to update support requirements for TLS 1.2 document updates RFC 7589 to update support requirements for TLS 1.2
and add TLS 1.3 support requirements, including restrictions on the and add TLS 1.3 support requirements, including restrictions on the
use of TLS 1.3's early data.</t> use of TLS 1.3's early data.</t>
</abstract> </abstract>
<note removeInRFC="true">
<name>About This Document</name>
<t>
The latest revision of this draft can be found at <eref target="https://
netconf-wg.github.io/netconf-over-tls13/draft-ietf-netconf-over-tls13.html"/>.
Status information for this document may be found at <eref target="https
://datatracker.ietf.org/doc/draft-ietf-netconf-over-tls13/"/>.
</t>
<t>
Discussion of this document takes place on the
Network Configuration Working Group mailing list (<eref target="mailto:n
etconf@ietf.org"/>),
which is archived at <eref target="https://mailarchive.ietf.org/arch/bro
wse/netconf/"/>.
Subscribe at <eref target="https://www.ietf.org/mailman/listinfo/netconf
/"/>.
</t>
<t>Source for this draft and an issue tracker can be found at
<eref target="https://github.com/netconf-wg/netconf-over-tls13"/>.</t>
</note>
</front> </front>
<middle> <middle>
<?line 50?>
<section anchor="introduction"> <section anchor="introduction">
<name>Introduction</name> <name>Introduction</name>
<t><xref target="RFC7589"/> defines how to protect NETCONF messages <xref target="RFC6241"/> with <t><xref target="RFC7589"/> defines how to protect NETCONF messages <xref target="RFC6241"/> with
TLS 1.2 <xref target="RFC5246"/>. This document updates <xref target="RFC7589"/> to update TLS 1.2 <xref target="RFC5246"/>. This document updates <xref target="RFC7589"/> to update
support requirements for TLS 1.2 <xref target="RFC5246"/> and to add TLS 1.3 <xr support requirements for TLS 1.2 <xref target="RFC5246"/> and add TLS 1.3 <xref
ef target="I-D.ietf-tls-rfc8446bis"/> target="RFC9846"/>
support requirements, including restrictions on the use of TLS 1.3's early data support requirements, including restrictions on the use of TLS 1.3's early data,
which is also known as 0-RTT data. which is also known as 0-RTT data.
It also updates the "netconf-tls" IANA Registered Port Number entry to It also updates "netconf-tls", the IANA-registered port number entry, to
refer to this document. All other provisions set forth in <xref target="RFC7589" /> refer to this document. All other provisions set forth in <xref target="RFC7589" />
are unchanged, including connection initiation, message framing, are unchanged, including connection initiation, message framing,
connection closure, certificate validation, server identity, and client connection closure, certificate validation, server identity, and client
identity.</t> identity.</t>
<aside> <aside>
<t>NOTE: Implementations that support TLS 1.3 <xref target="I-D.ietf-tls <t>NOTE: Implementations that support TLS 1.3 <xref target="RFC9846"/> s
-rfc8446bis"/> should hould
refer to TLS 1.3 <xref target="I-D.ietf-tls-rfc8446bis"/> in Sections <xref ta refer to TLS 1.3 in Sections <xref target="RFC7589" section="4" sectionFormat=
rget="RFC7589" section="4" sectionFormat="bare"/> and <xref target="RFC7589" sec "bare"/> and <xref target="RFC7589" section="5" sectionFormat="bare"/> of <xref
tion="5" sectionFormat="bare"/> of <xref target="RFC7589"/>.</t> target="RFC7589"/>.</t>
</aside> </aside>
</section> </section>
<section anchor="conventions-and-definitions"> <section anchor="conventions-and-definitions">
<name>Conventions and Definitions</name> <name>Conventions</name>
<t>The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14 <t>
>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQU
NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>RECO IRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL
MMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>", NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>
"<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to be i RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
nterpreted as "<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to
described in BCP 14 <xref target="RFC2119"/> <xref target="RFC8174"/> when, and be interpreted as
only when, they described in BCP&nbsp;14 <xref target="RFC2119"/> <xref target="RFC8174"/>
appear in all capitals, as shown here.</t> when, and only when, they appear in all capitals, as shown here.
<?line -18?> </t>
</section>
</section>
<section anchor="early-data"> <section anchor="early-data">
<name>Early Data</name> <name>Early Data</name>
<t>Early data (aka 0-RTT data) is a mechanism defined in TLS 1.3 <t>Early data (aka 0-RTT data) is a mechanism defined in TLS 1.3
<xref target="I-D.ietf-tls-rfc8446bis"/> that allows a client to send data ("ear ly data") <xref target="RFC9846"/> that allows a client to send data ("early data")
as part of the first flight of messages to a server. Note that TLS 1.3 can as part of the first flight of messages to a server. Note that TLS 1.3 can
be used without early data as per <xref section="F.5" sectionFormat="of" target= "I-D.ietf-tls-rfc8446bis"/>. be used without early data as per <xref section="F.5" sectionFormat="of" target= "RFC9846"/>.
In fact, early data is permitted by TLS 1.3 only when the client and server In fact, early data is permitted by TLS 1.3 only when the client and server
share a Pre-Shared Key (PSK), either obtained externally or via a previous share a Pre-Shared Key (PSK), either obtained externally or via a previous
handshake. The client uses the PSK to authenticate the server and to encrypt handshake. The client uses the PSK to authenticate the server and to encrypt
the early data.</t> the early data.</t>
<t>As noted in <xref section="2.3" sectionFormat="of" target="I-D.ietf-tls -rfc8446bis"/>, the security <t>As noted in <xref section="2.3" sectionFormat="of" target="RFC9846"/>, the security
properties for early data are weaker than those for subsequent TLS-protected properties for early data are weaker than those for subsequent TLS-protected
data. In particular, early data is not forward secret, and there is no data. In particular, early data is not forward secret, and there is no
protection against the replay of early data between connections. protection against the replay of early data between connections.
<xref section="E.5" sectionFormat="of" target="I-D.ietf-tls-rfc8446bis"/> requir es applications not <xref section="F.5" sectionFormat="of" target="RFC9846"/> requires applications not
use early data without a profile that defines its use. This document use early data without a profile that defines its use. This document
specifies that NETCONF implementations that support TLS 1.3 <bcp14>MUST NOT</bcp 14> use early specifies that NETCONF implementations that support TLS 1.3 <bcp14>MUST NOT</bcp 14> use early
data.</t> data.</t>
</section> </section>
<section anchor="cipher-suites"> <section anchor="cipher-suites">
<name>Cipher Suites</name> <name>Cipher Suites</name>
<t>Implementations <bcp14>MUST</bcp14> support mutually authenticated TLS 1.2 <xref target="RFC5246"/> and <t>Implementations <bcp14>MUST</bcp14> support mutually authenticated TLS 1.2 <xref target="RFC5246"/>, and
they are, as specified in <xref target="RFC9325"/>, recommended to support the c ipher they are, as specified in <xref target="RFC9325"/>, recommended to support the c ipher
suites found in <xref section="4.2" sectionFormat="of" target="RFC9325"/>.</t> suites found in <xref section="4.2" sectionFormat="of" target="RFC9325"/>.</t>
<t>Implementations <bcp14>MAY</bcp14> implement additional TLS 1.2 cipher suites that provide <t>Implementations <bcp14>MAY</bcp14> implement additional TLS 1.2 cipher suites that provide
mutual authentication <xref target="RFC5246"/> and confidentiality as required b y mutual authentication <xref target="RFC5246"/> and confidentiality, as required by
NETCONF <xref target="RFC6241"/>.</t> NETCONF <xref target="RFC6241"/>.</t>
<t>Implementations <bcp14>SHOULD</bcp14> support mutually authenticated TL S 1.3 <xref target="I-D.ietf-tls-rfc8446bis"/> and, <t>Implementations <bcp14>SHOULD</bcp14> support mutually authenticated TL S 1.3 <xref target="RFC9846"/> and,
if implemented, <bcp14>MUST</bcp14> prefer to negotiate TLS 1.3 over earlier ver sions if implemented, <bcp14>MUST</bcp14> prefer to negotiate TLS 1.3 over earlier ver sions
of TLS.</t> of TLS.</t>
<t>Implementations that support TLS 1.3 <xref target="I-D.ietf-tls-rfc8446 bis"/> are <t>Implementations that support TLS 1.3 <xref target="RFC9846"/> are
<bcp14>REQUIRED</bcp14> to support the mandatory-to-implement cipher suites list ed in <bcp14>REQUIRED</bcp14> to support the mandatory-to-implement cipher suites list ed in
<xref section="9.1" sectionFormat="of" target="I-D.ietf-tls-rfc8446bis"/>.</t> <xref section="9.1" sectionFormat="of" target="RFC9846"/>.</t>
<t>Implementations that support TLS 1.3 <bcp14>MAY</bcp14> implement addit ional TLS cipher <t>Implementations that support TLS 1.3 <bcp14>MAY</bcp14> implement addit ional TLS cipher
suites that provide mutual authentication and confidentiality, which are suites that provide mutual authentication and confidentiality, which are
required for NETCONF <xref target="RFC6241"/>.</t> required for NETCONF <xref target="RFC6241"/>.</t>
</section> </section>
<section anchor="security-considerations"> <section anchor="security-considerations">
<name>Security Considerations</name> <name>Security Considerations</name>
<t>The Security Considerations of <xref target="RFC6241"/>, <xref target=" RFC7589"/>, and <xref target="RFC9325"/> <t>The security considerations of <xref target="RFC6241"/>, <xref target=" RFC7589"/>, and <xref target="RFC9325"/>
apply here as well.</t> apply here as well.</t>
<t>NETCONF implementations <bcp14>SHOULD</bcp14> follow the TLS recommenda tions given in <t>NETCONF implementations <bcp14>SHOULD</bcp14> follow the TLS recommenda tions given in
<xref target="RFC9325"/>.</t> <xref target="RFC9325"/>.</t>
<t>For implementations that support TLS 1.3, the Security Considerations o <t>For implementations that support TLS 1.3, the security considerations o
f f
TLS 1.3 <xref target="I-D.ietf-tls-rfc8446bis"/> apply.</t> TLS 1.3 <xref target="RFC9846"/> apply.</t>
<t>As specified in <xref target="RFC7589"/>, NETCONF over TLS requires mut ual authentication.</t> <t>As specified in <xref target="RFC7589"/>, NETCONF over TLS requires mut ual authentication.</t>
<t>For implementations that support TLS 1.3 <xref target="I-D.ietf-tls-rfc <t>For implementations that support TLS 1.3 <xref target="RFC9846"/>:</t>
8446bis"/>:</t>
<ul empty="true"> <t indent="3">TLS 1.3 mutual authentication is used
<li>
<t>TLS 1.3 mutual authentication is used
to ensure that only authorized users and systems are able to view the to ensure that only authorized users and systems are able to view the
NETCONF server's configuration and state or to modify the NETCONF NETCONF server's configuration and state or to modify the NETCONF
server's configuration. To this end, neither the client nor the server server's configuration. To this end, neither the client nor the server
should establish a NETCONF over TLS 1.3 connection with an unknown, should establish a NETCONF over TLS 1.3 connection with an unknown,
unexpected, or incorrectly identified peer; see <xref section="7" sectionFormat= "of" target="RFC7589"/>. If unexpected, or incorrectly identified peer; see <xref section="7" sectionFormat= "of" target="RFC7589"/>. If
deployments make use of a trusted list of Certification Authority (CA) deployments make use of a trusted list of Certification Authority (CA)
certificates <xref target="RFC5280"/>, then the listed CAs should only issue cer tificates certificates <xref target="RFC5280"/>, then the listed CAs should only issue cer tificates
to parties that are authorized to access the NETCONF servers. Doing otherwise to parties that are authorized to access the NETCONF servers. Doing otherwise
will allow certificates that were issued for other purposes to be will allow certificates that were issued for other purposes to be
inappropriately accepted by a NETCONF server.</t> inappropriately accepted by a NETCONF server.</t>
</li>
</ul> <t>The security considerations of <xref target="RFC9525"/> apply to all im
<t>The Security Considerations of <xref target="RFC9525"/> apply to all im plementations
plementations
when the client checks the identity of the server, as is required in when the client checks the identity of the server, as is required in
<xref section="6" sectionFormat="of" target="RFC7589"/>.</t> <xref section="6" sectionFormat="of" target="RFC7589"/>.</t>
</section> </section>
<section anchor="iana-considerations"> <section anchor="iana-considerations">
<name>IANA Considerations</name> <name>IANA Considerations</name>
<t>IANA is requested to add a reference to this document in the <t>IANA has added a reference to this document in the
"netconf-tls" entry in the "Service Name and Transport Protocol Port "netconf-tls" entry in the "Service Name and Transport Protocol Port
Number Registry". The updated registry entry would appear as follows:</t> Number Registry". The updated registry entry appears as follows:</t>
<artwork><![CDATA[ <dl spacing="compact" newline="false">
Service Name: netconf-tls <dt>Service Name:</dt><dd>netconf-tls</dd>
Transport Protocol(s): TCP <dt>Port Number:</dt><dd>6513</dd>
Assignee: IESG <iesg@ietf.org> <dt>Transport Protocol:</dt><dd>tcp</dd>
Contact: IETF Chair <chair@ietf.org> <dt>Description:</dt><dd>NETCONF over TLS</dd>
Description: NETCONF over TLS <dt>Assignee:</dt><dd>IESG &lt;iesg@ietf.org&gt;</dd>
Reference: RFC 7589, [THIS RFC] <dt>Contact:</dt><dd>IETF Chair &lt;chair@ietf.org&gt;</dd>
Port Number: 6513 <dt>Reference:</dt><dd>RFC 7589, RFC 9918</dd>
]]></artwork> </dl>
</section> </section>
</middle> </middle>
<back> <back>
<references anchor="sec-normative-references"> <references anchor="sec-normative-references">
<name>Normative References</name> <name>Normative References</name>
<reference anchor="RFC7589"> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.75
<front> 89.xml"/>
<title>Using the NETCONF Protocol over Transport Layer Security (TLS) <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.62
with Mutual X.509 Authentication</title> 41.xml"/>
<author fullname="M. Badra" initials="M." surname="Badra"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.52
<author fullname="A. Luchuk" initials="A." surname="Luchuk"/> 46.xml"/>
<author fullname="J. Schoenwaelder" initials="J." surname="Schoenwaeld <!-- [I-D.ietf-tls-rfc8446bis] -> [RFC9846]
er"/> draft-ietf-tls-rfc8446bis-14
<date month="June" year="2015"/> companion doc RFC 9846 in AUTH48
<abstract> -->
<t>The Network Configuration Protocol (NETCONF) provides mechanisms <reference anchor="RFC9846" target="https://www.rfc-editor.org/info/rfc9846">
to install, manipulate, and delete the configuration of network devices. This do <front>
cument describes how to use the Transport Layer Security (TLS) protocol with mut <title>The Transport Layer Security (TLS) Protocol Version 1.3</title>
ual X.509 authentication to secure the exchange of NETCONF messages. This revisi <author initials="E." surname="Rescorla" fullname="Eric Rescorla">
on of RFC 5539 documents the new message framing used by NETCONF 1.1 and it obso <organization>Independent</organization>
letes RFC 5539.</t> </author>
</abstract> <date month="January" year="2026"/>
</front> </front>
<seriesInfo name="RFC" value="7589"/> <seriesInfo name="RFC" value="9846"/>
<seriesInfo name="DOI" value="10.17487/RFC7589"/> <seriesInfo name="DOI" value="10.17487/RFC9846"/>
</reference> </reference>
<reference anchor="RFC6241"> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.21
<front> 19.xml"/>
<title>Network Configuration Protocol (NETCONF)</title> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.81
<author fullname="R. Enns" initials="R." role="editor" surname="Enns"/ 74.xml"/>
> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.93
<author fullname="M. Bjorklund" initials="M." role="editor" surname="B 25.xml"/>
jorklund"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.52
<author fullname="J. Schoenwaelder" initials="J." role="editor" surnam 80.xml"/>
e="Schoenwaelder"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.95
<author fullname="A. Bierman" initials="A." role="editor" surname="Bie 25.xml"/>
rman"/>
<date month="June" year="2011"/>
<abstract>
<t>The Network Configuration Protocol (NETCONF) defined in this docu
ment provides mechanisms to install, manipulate, and delete the configuration of
network devices. It uses an Extensible Markup Language (XML)-based data encodin
g for the configuration data as well as the protocol messages. The NETCONF proto
col operations are realized as remote procedure calls (RPCs). This document obso
letes RFC 4741. [STANDARDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="6241"/>
<seriesInfo name="DOI" value="10.17487/RFC6241"/>
</reference>
<reference anchor="RFC5246">
<front>
<title>The Transport Layer Security (TLS) Protocol Version 1.2</title>
<author fullname="T. Dierks" initials="T." surname="Dierks"/>
<author fullname="E. Rescorla" initials="E." surname="Rescorla"/>
<date month="August" year="2008"/>
<abstract>
<t>This document specifies Version 1.2 of the Transport Layer Securi
ty (TLS) protocol. The TLS protocol provides communications security over the In
ternet. The protocol allows client/server applications to communicate in a way t
hat is designed to prevent eavesdropping, tampering, or message forgery. [STANDA
RDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="5246"/>
<seriesInfo name="DOI" value="10.17487/RFC5246"/>
</reference>
<reference anchor="I-D.ietf-tls-rfc8446bis">
<front>
<title>The Transport Layer Security (TLS) Protocol Version 1.3</title>
<author fullname="Eric Rescorla" initials="E." surname="Rescorla">
<organization>Windy Hill Systems, LLC</organization>
</author>
<date day="7" month="July" year="2023"/>
<abstract>
<t> This document specifies version 1.3 of the Transport Layer Sec
urity
(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.
This document updates RFCs 5705, 6066, 7627, and 8422 and obsoletes
RFCs 5077, 5246, 6961, and 8446. This document also specifies new
requirements for TLS 1.2 implementations.
</t>
</abstract>
</front>
<seriesInfo name="Internet-Draft" value="draft-ietf-tls-rfc8446bis-09"/>
</reference>
<reference anchor="RFC2119">
<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 signi
fy the requirements in the specification. These words are often capitalized. Thi
s document defines these words as they should be interpreted in IETF documents.
This document specifies an Internet Best Current Practices for the Internet Comm
unity, 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">
<front>
<title>Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words</titl
e>
<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 on
ly 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>
<reference anchor="RFC9325">
<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 Secur
ity (DTLS) are used to protect data exchanged over a wide range of application p
rotocols and can also form the basis for secure transport protocols. Over the ye
ars, the industry has witnessed several serious attacks on TLS and DTLS, includi
ng 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 publ
ished when the industry was transitioning to TLS 1.2. Years later, this transiti
on is largely complete, and TLS 1.3 is widely available. This document updates t
he 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>
<reference anchor="RFC5280">
<front>
<title>Internet X.509 Public Key Infrastructure Certificate and Certif
icate Revocation List (CRL) Profile</title>
<author fullname="D. Cooper" initials="D." surname="Cooper"/>
<author fullname="S. Santesson" initials="S." surname="Santesson"/>
<author fullname="S. Farrell" initials="S." surname="Farrell"/>
<author fullname="S. Boeyen" initials="S." surname="Boeyen"/>
<author fullname="R. Housley" initials="R." surname="Housley"/>
<author fullname="W. Polk" initials="W." surname="Polk"/>
<date month="May" year="2008"/>
<abstract>
<t>This memo profiles the X.509 v3 certificate and X.509 v2 certific
ate revocation list (CRL) for use in the Internet. An overview of this approach
and model is provided as an introduction. The X.509 v3 certificate format is des
cribed in detail, with additional information regarding the format and semantics
of Internet name forms. Standard certificate extensions are described and two I
nternet-specific extensions are defined. A set of required certificate extension
s is specified. The X.509 v2 CRL format is described in detail along with standa
rd and Internet-specific extensions. An algorithm for X.509 certification path v
alidation is described. An ASN.1 module and examples are provided in the appendi
ces. [STANDARDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="5280"/>
<seriesInfo name="DOI" value="10.17487/RFC5280"/>
</reference>
<reference anchor="RFC9525">
<front>
<title>Service Identity in TLS</title>
<author fullname="P. Saint-Andre" initials="P." surname="Saint-Andre"/
>
<author fullname="R. Salz" initials="R." surname="Salz"/>
<date month="November" year="2023"/>
<abstract>
<t>Many application technologies enable secure communication between
two entities by means of Transport Layer Security (TLS) with Internet Public Ke
y Infrastructure using X.509 (PKIX) certificates. This document specifies proced
ures for representing and verifying the identity of application services in such
interactions.</t>
<t>This document obsoletes RFC 6125.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="9525"/>
<seriesInfo name="DOI" value="10.17487/RFC9525"/>
</reference>
</references> </references>
<?line 180?>
<section numbered="false" anchor="acknowledgments"> <section numbered="false" anchor="acknowledgments">
<name>Acknowledgments</name> <name>Acknowledgments</name>
<t>We would like to thank Per Andersson, Jürgen Schönwälder, Jeff <t>We would like to thank <contact fullname="Per Andersson"/>, <contact fu
Hartley, Rob Wilton, and Qin Wu for their reviews.</t> llname="Jürgen Schönwälder"/>, <contact fullname="Jeff
Hartley"/>, <contact fullname="Rob Wilton"/>, and <contact fullname="Qin Wu"/> f
or their reviews.</t>
</section> </section>
</back> </back>
<!-- ##markdown-source:
H4sIAAAAAAAAA5VZy3YbNxLd4yswzGKsOSQl6mWbozhhJDlSoldEKh6fnCzA
bpDEUbO7B0CTZnz0L7OYb5jVrMY/NrcAdLNJUbLijdjoRqEet6puwa1Wi1ll
E9nld3ksrDTcZvzOqHTM7UTyq9PB8fXVe36jM5tFWcKzmdR8oEVq8kxbfiEW
eO7LqNDKLvirwUV/i8+VnfDLwhYi4f9oH+y85b0CwlKrImFVljIxHGo561bS
vdCLPsN7Oc70osuNjRmLsygVU+gWazGyLSXtqJVKG2XpqEV7WjYxnb3Wzj4z
xXCqjIFwu8ix4fx08J7hOyNTU5gut7qQDCfuscKb2eWvD968ZUJL0eWN61xq
p5rhIo35pUjFWE6hcYPNM30/1lmR47MraemRH0MBNS78lga7lwssx13GW6VJ
9BMG8U57b/lzl36eCp0s+Imwgs1kWkjs4l+Rz7k3qvEBLykyP9L3tD4VKsF6
8Mn35KB2psf0SuhoglcTa3PT3d6mL2lJzWS7/GybFraHOpsbuR1kbNPeMQJY
DJeCW/Px9mO/05cJ+dLWzlnuaHspbZVt2Lv9bETbEztNGowJwCbT5FccxblK
EbZ+mw8KnUrtljw8+lKk9VXYJlL1h3MfoJTu6ditS+8vg8+/d6vtKJuW0r2o
28IYfpYVJpGLUlaX/6rGKqlg3uQXF8fuZQnk1ffulbFaSnjmoHPIT5Av0sxU
kkh+mwmvTIQvu/xM6jTO0ib/tedXsxha7O50Xu+E5yK1lBB3/boJE6/h9zM6
2MjIGcJYq9WCTjhaRJax2/fHDuU8liMFBbBrTumdI5llZKv0m0pjgHfjEzdg
FW6eKEMpWFAi8JA3vBIKQX6NmyJ3xUDLfxZKu7wxfJTpCvaUUyKOy4zYuKGJ
8EZJERO+NTClVeQTMkupErHCSJ6NShF/NVy6RIICou0Nn6o4TiRj3/BzuCyL
CyeAsc+f/wKlSeeHhxe7wm863N3vYBP5hQVjwpuD3f3DhwfvJP7ISZ8/L0+s
/MS+5ie/zUt2dQhb627DyeetE5e+lCctPYre7O8fDpV5eNgo/Cs+5c/4lM8n
KppwGCcSk/H7NJunXBi+07odDILXz61/WVpNIquSAQUb/Lx31eO3cqyMlVrG
/IY0vCqmQ9R7SbiGiUzLER5hq637ss17CdoNZGqK0kwZp7mRllwGnKq07maq
5LxIo4lIxzKuGw5tUunsxqKyylWFZhlpPtJiis+arPZdlGSm0LLJI6mtGlHb
knwmEhWHzUZqalkqpqZGBYGiFSUKj6xcBCqPhMETqrS+j+G/bxvDJIvuG++Q
yVfXg1O0qWmeuFCF5mMnwlbZsQz7k1HnBoUgoXpSOfElYPG+68uAhn2n/gFB
ofJnmx1tO+3fMcoodKQZmVV2yBNKI+WeGRsg7uiBnJqg4Y3Lu/6g0fR/yU76
fXv6y9357ekJ/e6f9S4uqh8sfNE/u767OFn+Wu48vr68PL068ZuxyleWWOOy
97HhI9C4vhmcX1/1Lhpk4QqcOOED7hlKvAIYcy0tAClQ4aSJtBriAXt+OL75
3786+yHJdzsdymD/8Kbzep9qAYiMPy1LkSv+EShdMJHnyB+SIoDcSOTKIj2a
lDUIE9IHUJZAxd9+I8/83uVHwyjv7L8LC2TwymLps5VF57PHK482eyduWNpw
TOXNlfU1T6/q2/u48lz6vbZ49F2CQstbnTffeQjViA87XdaZV+Je1KrKlis5
yE7KZGWmoWC74JSE6rmEcBkE/4PTQIxPSYo7iGAcDmwsq1xjiyE6uUC2AfxU
v0ZKG1SYRI0nbq1qCFSLQ963+RW6hj+qTLdIpGzoKmrs2kVW2Ho1pVOQn1XS
8fdtl29PGoLqmvIR2nizLkY5MVNlCbvDRXV6BUVnQ7CaMOoVZmZC8Beg8bLV
p98x/xkJ++qm//MWDlCuymZDK5yr5SckSAonLsB++ExBfZRgOVMgHQxhiSHu
XlLvq86C3b7+Q6Jz1ZLwS7ceKmboajKN9CK3jN6s9PGe4WlmfbiXztolE59x
VjMcEegX2kVOhVv67loPA7wwl1BeU/TIWxlaIH2EAcKgc5ItcGor8AIZM6cY
GIVDiYoKsOj1kEBjkjEXmhweobL4AkFelf4DFgSSNWIMNwNkpLOWeSIWZFxN
5BBjgEQslx3JtAH6HupLGqtP/PQr2Ck5ADIgz5MwdDk1HYuqN/mAVIpvNlJJ
AHVJkhT4CXassRxmchmhK8rQr0rupF7SzMpKxytNWAg9mozKCYf9QoFNMLbe
HN3WUt7UjZewo460+CkmRUBbUPR9NQ76B5RRcX+7t3tAONISRBpnxtLhtDzN
ZZXTDjyLtEO8i3QNpfs417dQL629wYTex6WbiNu5FooxudTbH8LDIc6DjvzE
knmL6/bSoeuUkbiXZyCgK5jIYW5AAxUMVsbKbfPsdoOaoVO8yNfP8xOo1GRq
tDSauJkLZF4xlhQjP9EyuSxnVCoIHAp/8dtRP+aZ6gZ1/zRrAhBY2V3XwzyF
ysJmetGyWWsZq9XAJERoKfxsGf637c5XKvrLFH8WI6sgrOODb8bHBkw0A7cn
L1TYoBq4GRzfLK93wAKJEoarEk/8nnhJrqjJada5uq+ObsFnClEnwMuVSwB2
LpMEBz9VVwI6Rxl1eRcz8kyVueGrsQJh9RGqZ+R72PmSQuVbytPGsRfhjMzy
XW2t5tR8sX4JtqzeGyP6J2x4TrcuY++q7zZDR7nij9pJ/ZrmIX+I4xr+Zkb9
AXvwjfZDgVkgK6bGdVkxTBzfninpYlRF0xMBzJpR/ZLL77dUBDJXFKZZrEaL
+h0k27wTzSlMjoh9E8XEk5kaD0ozXaMgzI9MHOMwdFQGefA4BI7RLedBdy8C
ulCkbg5usiKVn3LHD5qkL4bNTAOAFp7xieYinUup/45jZa1JvF6dsvj5CANI
nmQLfxswBTcpx3JBt5auzlC5oZXjahwlUT0fA7p2Pe5tsdqsaqpLijc7gR15
Zhjq1nHPhMnRR1MZU8j6sGso6I7wlFXGxXQZdKJ4UQRuvHJL7D1s2vwko8nb
De9zZSSbK0xEjpWvnOJFzz1Lggq+DIWZv9B5ZjzxHkqmUiQTeJ2mRkEAxOl5
YMFiTYH2CyqTa/oHVBR8ljqLoORaXrF1Uh1NZHTvrS4H/XJ08Ic7hqFqXXel
SRyuDdl0WUV3JOuV1S0GKdLFLNwFCT/pg0DLR1cmfuiVbPUOxt+z+FcYrqGk
wt4rMZUu6ZZ3+dUdP93SsHBL4y9v9KLh6b6/6omhhF8O0ucOS2EAFibUZoMi
Q3eWvH5oly//1fT0Hz5W5pXZwo7B8Y3/oGeMGqdyRQr9Oz/t/8iPgNZxdQn+
zu+AZy3GqPUN7n8I+PFEKM2PIvqzvvHE3Qvk/g659u/Rf1q41dsyKmsHldel
Tf7b4Oy8T8+/+x21u7CVPYcHnb1wlTsU0T1BpBdR3UlkPHZVgn3upm6fjL9t
jERiZOOBsQ8yhCFR9wEbIr3nN9CyBz6rjaGbq5++/FePAel+NPnyn3T+5d9J
TJj9SY5G7AwJn0jwg9tsyD+oxGbhpuMXoOdD4ZITIILHaBiUc0wl/wf3IVnT
QBoAAA==
</rfc> </rfc>
 End of changes. 35 change blocks. 
358 lines changed or deleted 112 lines changed or added

This html diff was produced by rfcdiff 1.48.