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

<!DOCTYPE rfc [
  <!ENTITY nbsp    "&#160;">
  <!ENTITY zwsp   "&#8203;">
  <!ENTITY nbhy   "&#8209;">
  <!ENTITY wj     "&#8288;">
]>

<rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft-ietf-pce-pceps-tls13-04" number="9916" category="std" consensus="true" submissionType="IETF" updates="8253" obsoletes="" tocInclude="true" sortRefs="true" symRefs="true" version="3" xml:lang="en">

  <front>
    <title abbrev="Updates for PCEPS">Updates to the Usage of TLS to Provide a Secure Transport for the Path Computation Element Communication Protocol (PCEP)</title>
    <seriesInfo name="RFC" value="9916"/>
    <author initials="D." surname="Dhody" fullname="Dhruv Dhody">
      <organization>Huawei</organization>
      <address>
        <email>dhruv.ietf@gmail.com</email>
      </address>
    </author>
    <author initials="S." surname="Turner" fullname="Sean Turner">
      <organization>sn3rd</organization>
      <address>
        <email>sean@sn3rd.com</email>
      </address>
    </author>
    <author initials="R." surname="Housley" fullname="Russ Housley">
      <organization abbrev="Vigil Security">Vigil Security, LLC</organization>
      <address>
        <postal>
          <street>516 Dranesville Road</street>
          <city>Herndon</city>
	  <region>VA</region>
          <code>20170</code>
          <country>United States of America</country>
        </postal>
        <email>housley@vigilsec.com</email>
      </address>
    </author>
    <date year="2026" month="January"/>
    <area>RTG</area>
    <workgroup>pce</workgroup>
    <keyword>PCEP</keyword>
    <keyword>PCEPS</keyword>
    <keyword>TLS 1.3</keyword>
    <keyword>TLS 1.2</keyword>
    <keyword>Early Data</keyword>
    <keyword>0-RTT</keyword>
    <abstract>
<t>Section 3.4 of RFC 8253 specifies TLS connection establishment restrictions
for PCEPS; PCEPS refers to usage of TLS to provide a secure transport for the Path Computation Element Communication Protocol (PCEP).  This document adds
restrictions to specify what PCEPS implementations do if they support
more than one version of the TLS protocol and to restrict the use of
TLS 1.3's early data.</t>
    </abstract>
  </front>
  <middle>
    <section anchor="introduction">
      <name>Introduction</name>
      <t><xref section="3.4" sectionFormat="of" target="RFC8253"/> specifies TLS connection establishment
restrictions for PCEPS; PCEPS refers to usage of TLS to
provide a secure transport for the Path Computation Element
Communication Protocol (PCEP) <xref target="RFC5440"/>.  This document adds restrictions to specify
what PCEPS implementations do if they support more than one version of
the TLS protocol, e.g., TLS 1.2 <xref target="RFC5246"/> and
TLS 1.3 <xref target="RFC9846"/>, and to restrict the use of
TLS 1.3's early data, which is also known as 0-RTT data. All other
provisions set forth in <xref target="RFC8253"/> are unchanged, including connection
initiation, message framing, connection closure, certificate validation,
peer identity, and failure handling.</t>
    </section>
    <section anchor="conventions-and-definitions">
      <name>Conventions</name>
        <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&nbsp;14 <xref target="RFC2119"/> <xref target="RFC8174"/> 
    when, and only when, they appear in all capitals, as shown here.
        </t>
    </section>
    <section anchor="tls-connection-establishment-restrictions">
      <name>TLS Connection Establishment Restrictions</name>
      <t>Step 1 in <xref section="3.4" sectionFormat="of" target="RFC8253"/> includes restrictions on PCEPS TLS connection
establishment. This document adds the following restrictions:</t>
      <ul spacing="normal">
        <li>
          <t>Implementations that support multiple versions of the TLS protocol <bcp14>MUST</bcp14>
prefer to negotiate the latest version of the TLS protocol; see
<xref section="4.2.1" sectionFormat="of" target="RFC9846"/>.</t>
        </li>
        <li>
          <t>PCEPS implementations that support TLS 1.3 or later <bcp14>MUST NOT</bcp14> use early data.</t>
        </li>
      </ul>

<aside><t>NOTE: Early data (aka 0-RTT data) is a mechanism defined in TLS 1.3
<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 be used without early data as per <xref section="F.5" target="RFC9846"/>.  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 handshake.  The client
uses the PSK to authenticate the server and to encrypt the early
data.</t></aside>

<aside><t>NOTE: 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 data.  In particular, early
data is not forward secret, and there is no protection against the replay of
early data between connections.  <xref section="E.5" sectionFormat="of"
target="RFC9846"/> requires applications not use early data
without a profile that defines its use.</t></aside>

    </section>
    <section anchor="security-considerations">
      <name>Security Considerations</name>   
      <t>The security considerations of PCEP <xref target="RFC5440"/> <xref target="RFC8231"/> <xref target="RFC8253"/>
<xref target="RFC8281"/> <xref target="RFC8283"/>, TLS 1.2 <xref target="RFC5246"/>, TLS 1.3 <xref target="RFC9846"/>,
and TLS&wj;/DTLS recommendations <xref target="RFC9325"/> apply here as well.</t>
    </section>
    <section anchor="iana-considerations">
      <name>IANA Considerations</name>
      <t>This document has no IANA actions.</t>
    </section>

  </middle>
  <back>

    <references>
      <name>References</name>
      <references anchor="sec-normative-references">
        <name>Normative References</name>

	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8253.xml"/>
	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5440.xml"/>
	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5246.xml"/>
<!-- [I-D.ietf-tls-rfc8446bis] -> [RFC9846]
draft-ietf-tls-rfc8446bis-14
companion doc RFC 9846
in AUTH48 as of 1/16/26
-->
<reference anchor="RFC9846" target="https://www.rfc-editor.org/info/rfc9846">
  <front>
      <title>The Transport Layer Security (TLS) Protocol Version 1.3</title>
      <author initials="E." surname="Rescorla" fullname="Eric Rescorla">
         <organization>Independent</organization>
      </author>
    <date month="January" year="2026"/>
  </front>
  <seriesInfo name="RFC" value="9846"/>
  <seriesInfo name="DOI" value="10.17487/RFC9846"/>
</reference>

	<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"/>
	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9325.xml"/>

      </references>
      <references anchor="sec-informative-references">
        <name>Informative References</name>

	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8231.xml"/>
	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8281.xml"/>
	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8283.xml"/>

      </references>
    </references>

<section numbered="false" anchor="acknowledgments">
      <name>Acknowledgments</name>
      <t>We would like to thank <contact fullname="Adrian Farrel"/>, <contact fullname="Stephane Litkowski"/>, <contact fullname="Cheng Li"/>, and
<contact fullname="Andrew Stone"/> for their review.</t>
    </section>
  </back>
</rfc>
