<?xml version='1.0' encoding='utf-8'?>
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" version="3" category="std" docName="draft-ietf-opsawg-mud-tls-18" number="9761" ipr="trust200902" obsoletes="" updates="" submissionType="IETF" xml:lang="en" tocInclude="true" tocDepth="3" consensus="true" symRefs="true" sortRefs="true" prepTime="2025-04-18T13:52:54" indexInclude="true" scripts="Common,Latin">
  <link href="https://datatracker.ietf.org/doc/draft-ietf-opsawg-mud-tls-18" rel="prev"/>
  <link href="https://dx.doi.org/10.17487/rfc9761" rel="alternate"/>
  <link href="urn:issn:2070-1721" rel="alternate"/>
  <front>
    <title abbrev="MUD (D)TLS Profile for IoT Devices">Manufacturer Usage Description (MUD) for TLS and DTLS Profiles for Internet of Things (IoT) Devices</title>
    <seriesInfo name="RFC" value="9761" stream="IETF"/>
    <author fullname="Tirumaleswar Reddy.K" initials="T." surname="Reddy.K">
      <organization showOnFrontPage="true">Nokia</organization>
      <address>
        <postal>
          <country>India</country>
        </postal>
        <email>kondtir@gmail.com</email>
      </address>
    </author>
    <author fullname="Dan Wing" initials="D." surname="Wing">
      <organization abbrev="Citrix" showOnFrontPage="true">Citrix Systems, Inc.</organization>
      <address>
        <postal>
          <street>4988 Great America Pkwy</street>
          <city>Santa Clara</city>
          <region>CA</region>
          <code>95054</code>
          <country>United States of America</country>
        </postal>
        <email>danwing@gmail.com</email>
      </address>
    </author>
    <author fullname="Blake Anderson" initials="B." surname="Anderson">
      <organization abbrev="Cisco" showOnFrontPage="true">Cisco Systems, Inc.</organization>
      <address>
        <postal>
          <street>170 West Tasman Dr</street>
          <city>San Jose</city>
          <region>CA</region>
          <code>95134</code>
          <country>United States of America</country>
        </postal>
        <email>blake.anderson@cisco.com</email>
      </address>
    </author>
    <date month="04" year="2025"/>
    <area>OPS</area>
    <workgroup>opsawg</workgroup>
    <keyword>Network Security Access Control Lists (ACLs)</keyword>
    <keyword>Firewall Policies</keyword>
    <keyword>Certificate Validation</keyword>
    <keyword>Unauthorized Software Detection</keyword>
    <keyword>Malware Detection</keyword>
    <abstract pn="section-abstract">
      <t indent="0" pn="section-abstract-1">This memo extends the Manufacturer Usage Description (MUD)
      specification to allow manufacturers to define TLS and DTLS profile
      parameters. This allows a network security service to identify
      unexpected (D)TLS usage, which can indicate the presence of unauthorized
      software, malware, or security policy-violating traffic on an
      endpoint.</t>
    </abstract>
    <boilerplate>
      <section anchor="status-of-memo" numbered="false" removeInRFC="false" toc="exclude" pn="section-boilerplate.1">
        <name slugifiedName="name-status-of-this-memo">Status of This Memo</name>
        <t indent="0" pn="section-boilerplate.1-1">
            This is an Internet Standards Track document.
        </t>
        <t indent="0" pn="section-boilerplate.1-2">
            This document is a product of the Internet Engineering Task Force
            (IETF).  It represents the consensus of the IETF community.  It has
            received public review and has been approved for publication by
            the Internet Engineering Steering Group (IESG).  Further
            information on Internet Standards is available in Section 2 of 
            RFC 7841.
        </t>
        <t indent="0" pn="section-boilerplate.1-3">
            Information about the current status of this document, any
            errata, and how to provide feedback on it may be obtained at
            <eref target="https://www.rfc-editor.org/info/rfc9761" brackets="none"/>.
        </t>
      </section>
      <section anchor="copyright" numbered="false" removeInRFC="false" toc="exclude" pn="section-boilerplate.2">
        <name slugifiedName="name-copyright-notice">Copyright Notice</name>
        <t indent="0" pn="section-boilerplate.2-1">
            Copyright (c) 2025 IETF Trust and the persons identified as the
            document authors. All rights reserved.
        </t>
        <t indent="0" pn="section-boilerplate.2-2">
            This document is subject to BCP 78 and the IETF Trust's Legal
            Provisions Relating to IETF Documents
            (<eref target="https://trustee.ietf.org/license-info" brackets="none"/>) in effect on the date of
            publication of this document. Please review these documents
            carefully, as they describe your rights and restrictions with
            respect to this document. Code Components extracted from this
            document must include Revised BSD License text as described in
            Section 4.e of the Trust Legal Provisions and are provided without
            warranty as described in the Revised BSD License.
        </t>
      </section>
    </boilerplate>
    <toc>
      <section anchor="toc" numbered="false" removeInRFC="false" toc="exclude" pn="section-toc.1">
        <name slugifiedName="name-table-of-contents">Table of Contents</name>
        <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1">
          <li pn="section-toc.1-1.1">
            <t indent="0" keepWithNext="true" pn="section-toc.1-1.1.1"><xref derivedContent="1" format="counter" sectionFormat="of" target="section-1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-introduction">Introduction</xref></t>
          </li>
          <li pn="section-toc.1-1.2">
            <t indent="0" keepWithNext="true" pn="section-toc.1-1.2.1"><xref derivedContent="2" format="counter" sectionFormat="of" target="section-2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-terminology">Terminology</xref></t>
          </li>
          <li pn="section-toc.1-1.3">
            <t indent="0" keepWithNext="true" pn="section-toc.1-1.3.1"><xref derivedContent="3" format="counter" sectionFormat="of" target="section-3"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-overview-of-mud-dtls-profil">Overview of MUD (D)TLS Profiles for IoT devices</xref></t>
          </li>
          <li pn="section-toc.1-1.4">
            <t indent="0" pn="section-toc.1-1.4.1"><xref derivedContent="4" format="counter" sectionFormat="of" target="section-4"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-dtls-13-handshake">(D)TLS 1.3 Handshake</xref></t>
            <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.4.2">
              <li pn="section-toc.1-1.4.2.1">
                <t indent="0" pn="section-toc.1-1.4.2.1.1"><xref derivedContent="4.1" format="counter" sectionFormat="of" target="section-4.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-full-dtls-13-handshake-insp">Full (D)TLS 1.3 Handshake Inspection</xref></t>
              </li>
              <li pn="section-toc.1-1.4.2.2">
                <t indent="0" pn="section-toc.1-1.4.2.2.1"><xref derivedContent="4.2" format="counter" sectionFormat="of" target="section-4.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-encrypted-dns">Encrypted DNS</xref></t>
              </li>
            </ul>
          </li>
          <li pn="section-toc.1-1.5">
            <t indent="0" pn="section-toc.1-1.5.1"><xref derivedContent="5" format="counter" sectionFormat="of" target="section-5"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-dtls-profile-of-an-iot-devi">(D)TLS Profile of an IoT device</xref></t>
            <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.5.2">
              <li pn="section-toc.1-1.5.2.1">
                <t indent="0" pn="section-toc.1-1.5.2.1.1"><xref derivedContent="5.1" format="counter" sectionFormat="of" target="section-5.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-tree-structure-of-the-dtls-">Tree Structure of the (D)TLS Profile Extension to the ACL YANG Module</xref></t>
              </li>
              <li pn="section-toc.1-1.5.2.2">
                <t indent="0" pn="section-toc.1-1.5.2.2.1"><xref derivedContent="5.2" format="counter" sectionFormat="of" target="section-5.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-the-dtls-profile-extension-">The (D)TLS Profile Extension to the ACL YANG Module</xref></t>
              </li>
              <li pn="section-toc.1-1.5.2.3">
                <t indent="0" pn="section-toc.1-1.5.2.3.1"><xref derivedContent="5.3" format="counter" sectionFormat="of" target="section-5.3"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-iana-dtls-profile-yang-modu">IANA (D)TLS Profile YANG Module</xref></t>
              </li>
              <li pn="section-toc.1-1.5.2.4">
                <t indent="0" pn="section-toc.1-1.5.2.4.1"><xref derivedContent="5.4" format="counter" sectionFormat="of" target="section-5.4"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-mud-dtls-profile-extension">MUD (D)TLS Profile Extension</xref></t>
              </li>
            </ul>
          </li>
          <li pn="section-toc.1-1.6">
            <t indent="0" pn="section-toc.1-1.6.1"><xref derivedContent="6" format="counter" sectionFormat="of" target="section-6"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-processing-of-the-mud-dtls-">Processing of the MUD (D)TLS Profile</xref></t>
          </li>
          <li pn="section-toc.1-1.7">
            <t indent="0" pn="section-toc.1-1.7.1"><xref derivedContent="7" format="counter" sectionFormat="of" target="section-7"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-mud-file-example">MUD File Example</xref></t>
          </li>
          <li pn="section-toc.1-1.8">
            <t indent="0" pn="section-toc.1-1.8.1"><xref derivedContent="8" format="counter" sectionFormat="of" target="section-8"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-software-based-acls-and-acl">Software-Based ACLs and ACLs Within a (D)TLS 1.3 Proxy</xref></t>
          </li>
          <li pn="section-toc.1-1.9">
            <t indent="0" pn="section-toc.1-1.9.1"><xref derivedContent="9" format="counter" sectionFormat="of" target="section-9"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-security-considerations">Security Considerations</xref></t>
            <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.9.2">
              <li pn="section-toc.1-1.9.2.1">
                <t indent="0" pn="section-toc.1-1.9.2.1.1"><xref derivedContent="9.1" format="counter" sectionFormat="of" target="section-9.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-challenges-in-mimicking-dtl">Challenges in Mimicking (D)TLS 1.2 Handshakes for IoT Devices</xref></t>
              </li>
              <li pn="section-toc.1-1.9.2.2">
                <t indent="0" pn="section-toc.1-1.9.2.2.1"><xref derivedContent="9.2" format="counter" sectionFormat="of" target="section-9.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-considerations-for-the-iana">Considerations for the "iana-tls-profile" Module</xref></t>
              </li>
              <li pn="section-toc.1-1.9.2.3">
                <t indent="0" pn="section-toc.1-1.9.2.3.1"><xref derivedContent="9.3" format="counter" sectionFormat="of" target="section-9.3"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-considerations-for-the-ietf">Considerations for the "ietf-acl-tls" Module</xref></t>
              </li>
              <li pn="section-toc.1-1.9.2.4">
                <t indent="0" pn="section-toc.1-1.9.2.4.1"><xref derivedContent="9.4" format="counter" sectionFormat="of" target="section-9.4"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-considerations-for-the-ietf-">Considerations for the "ietf-mud-tls" Module</xref></t>
              </li>
            </ul>
          </li>
          <li pn="section-toc.1-1.10">
            <t indent="0" pn="section-toc.1-1.10.1"><xref derivedContent="10" format="counter" sectionFormat="of" target="section-10"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-privacy-considerations">Privacy Considerations</xref></t>
          </li>
          <li pn="section-toc.1-1.11">
            <t indent="0" pn="section-toc.1-1.11.1"><xref derivedContent="11" format="counter" sectionFormat="of" target="section-11"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-iana-considerations">IANA Considerations</xref></t>
            <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.11.2">
              <li pn="section-toc.1-1.11.2.1">
                <t indent="0" pn="section-toc.1-1.11.2.1.1"><xref derivedContent="11.1" format="counter" sectionFormat="of" target="section-11.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-dtls-profile-yang-modules">(D)TLS Profile YANG Modules</xref></t>
              </li>
              <li pn="section-toc.1-1.11.2.2">
                <t indent="0" pn="section-toc.1-1.11.2.2.1"><xref derivedContent="11.2" format="counter" sectionFormat="of" target="section-11.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-considerations-for-the-iana-">Considerations for the iana-tls-profile Module</xref></t>
              </li>
              <li pn="section-toc.1-1.11.2.3">
                <t indent="0" pn="section-toc.1-1.11.2.3.1"><xref derivedContent="11.3" format="counter" sectionFormat="of" target="section-11.3"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-acl-tls-version-registry">ACL TLS Version Registry</xref></t>
              </li>
              <li pn="section-toc.1-1.11.2.4">
                <t indent="0" pn="section-toc.1-1.11.2.4.1"><xref derivedContent="11.4" format="counter" sectionFormat="of" target="section-11.4"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-acl-dtls-version-registry">ACL DTLS Version Registry</xref></t>
              </li>
              <li pn="section-toc.1-1.11.2.5">
                <t indent="0" pn="section-toc.1-1.11.2.5.1"><xref derivedContent="11.5" format="counter" sectionFormat="of" target="section-11.5"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-acl-dtls-parameters-registr">ACL (D)TLS Parameters Registry</xref></t>
              </li>
              <li pn="section-toc.1-1.11.2.6">
                <t indent="0" pn="section-toc.1-1.11.2.6.1"><xref derivedContent="11.6" format="counter" sectionFormat="of" target="section-11.6"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-mud-extensions-registry">MUD Extensions Registry</xref></t>
              </li>
            </ul>
          </li>
          <li pn="section-toc.1-1.12">
            <t indent="0" pn="section-toc.1-1.12.1"><xref derivedContent="12" format="counter" sectionFormat="of" target="section-12"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-references">References</xref></t>
            <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.12.2">
              <li pn="section-toc.1-1.12.2.1">
                <t indent="0" pn="section-toc.1-1.12.2.1.1"><xref derivedContent="12.1" format="counter" sectionFormat="of" target="section-12.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-normative-references">Normative References</xref></t>
              </li>
              <li pn="section-toc.1-1.12.2.2">
                <t indent="0" pn="section-toc.1-1.12.2.2.1"><xref derivedContent="12.2" format="counter" sectionFormat="of" target="section-12.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-informative-references">Informative References</xref></t>
              </li>
            </ul>
          </li>
          <li pn="section-toc.1-1.13">
            <t indent="0" pn="section-toc.1-1.13.1"><xref derivedContent="" format="none" sectionFormat="of" target="section-appendix.a"/><xref derivedContent="" format="title" sectionFormat="of" target="name-acknowledgments">Acknowledgments</xref></t>
          </li>
          <li pn="section-toc.1-1.14">
            <t indent="0" pn="section-toc.1-1.14.1"><xref derivedContent="" format="none" sectionFormat="of" target="section-appendix.b"/><xref derivedContent="" format="title" sectionFormat="of" target="name-authors-addresses">Authors' Addresses</xref></t>
          </li>
        </ul>
      </section>
    </toc>
  </front>
  <middle>
    <section anchor="intro" numbered="true" toc="include" removeInRFC="false" pn="section-1">
      <name slugifiedName="name-introduction">Introduction</name>
      <t indent="0" pn="section-1-1">Encryption is necessary to enhance the privacy of end users using Internet of Things (IoT)
      devices. TLS <xref target="RFC8446" format="default" sectionFormat="of" derivedContent="RFC8446"/> and DTLS <xref target="RFC9147" format="default" sectionFormat="of" derivedContent="RFC9147"/> are the dominant protocols (counting all (D)TLS
      versions) that provide encryption for IoT device traffic. Unfortunately, in
      conjunction with IoT applications' rise of encryption, malware authors
      are also using encryption that thwarts network-based analysis, such as
      deep packet inspection (DPI). Thus, other mechanisms are needed to help
      detect malware running on an IoT device.</t>
      <t indent="0" pn="section-1-2">Malware often reuses certain libraries, and there are notable
      differences in how malware uses encryption compared to software that is not malware.
      Several common patterns in the use of (D)TLS by malware include: </t>
      <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-1-3">
        <li pn="section-1-3.1">
          <t indent="0" pn="section-1-3.1.1">Use of older and weaker cryptographic parameters.</t>
        </li>
        <li pn="section-1-3.2">
          <t indent="0" pn="section-1-3.2.1">TLS server name indication (SNI) extension <xref target="RFC6066" format="default" sectionFormat="of" derivedContent="RFC6066"/> and server certificates are composed of
          subjects with characteristics of a domain generation algorithm (DGA)
          (e.g., "www.33mhwt2j.net").</t>
        </li>
        <li pn="section-1-3.3">
          <t indent="0" pn="section-1-3.3.1">Higher use of self-signed certificates compared with typical
          legitimate software using certificates from a certificate authority (CA) trusted by the
          device.</t>
        </li>
        <li pn="section-1-3.4">
          <t indent="0" pn="section-1-3.4.1">Discrepancies in the SNI TLS extension and the DNS names in the
          SubjectAltName (SAN) X.509 extension in the server Certificate
          message.</t>
        </li>
        <li pn="section-1-3.5">
          <t indent="0" pn="section-1-3.5.1">Discrepancies in the key exchange algorithm and the client public
          key length in comparison with legitimate flows. As a reminder, the
          Client Key Exchange message has been removed from TLS 1.3.</t>
        </li>
        <li pn="section-1-3.6">
          <t indent="0" pn="section-1-3.6.1">Lower diversity in extensions advertised by TLS clients compared to
          legitimate clients.</t>
        </li>
        <li pn="section-1-3.7">
          <t indent="0" pn="section-1-3.7.1">Using privacy enhancing technologies like Tor, Psiphon, Ultrasurf
          (see <xref target="MALWARE-TLS" format="default" sectionFormat="of" derivedContent="MALWARE-TLS"/>), and evasion techniques
          such as ClientHello randomization.</t>
        </li>
        <li pn="section-1-3.8">
          <t indent="0" pn="section-1-3.8.1">Using an alternative DNS server (via encrypted transport) to
          avoid detection by malware DNS filtering services <xref target="MALWARE-DOH" format="default" sectionFormat="of" derivedContent="MALWARE-DOH"/>. Specifically, malware may not use the
          Do53 or encrypted DNS server provided by the local network (DHCP,
          Discovery of Network-designated Resolvers (DNR) <xref target="RFC9463" format="default" sectionFormat="of" derivedContent="RFC9463"/>, or Discovery of Designated Resolvers (DDR) <xref target="RFC9462" format="default" sectionFormat="of" derivedContent="RFC9462"/>).</t>
        </li>
      </ul>
      <t indent="0" pn="section-1-4">If (D)TLS profile parameters are defined, the following functions that have a positive impact on the local network security are possible:</t>
      <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-1-5">
        <li pn="section-1-5.1">
          <t indent="0" pn="section-1-5.1.1">Permit intended DTLS or TLS use, and block malicious DTLS or
          TLS use.

This is superior to the Access Control Lists
          (ACLs) of Layers 3 and 4 in "Manufacturer Usage Description Specification" <xref target="RFC8520" format="default" sectionFormat="of" derivedContent="RFC8520"/>, which are not suitable for broad
          communication patterns. The goal of this document is to enhance and
          complement the existing MUD specifications rather than undermine
          them.</t>
        </li>
        <li pn="section-1-5.2">
          <t indent="0" pn="section-1-5.2.1">Ensure TLS certificates are valid. Several TLS deployments have
          been vulnerable to active Man-In-The-Middle (MITM) attacks because
          of the lack of certificate validation or vulnerability in the
          certificate validation function (see <xref target="CRYPTO-VULNERABILITY" format="default" sectionFormat="of" derivedContent="CRYPTO-VULNERABILITY"/>). By observing (D)TLS profile
          parameters, a network element can detect when the TLS SNI mismatches
          the SubjectAltName and when the server's certificate is invalid. In
          (D)TLS 1.2 <xref target="RFC5246" format="default" sectionFormat="of" derivedContent="RFC5246"/> <xref target="RFC6347" format="default" sectionFormat="of" derivedContent="RFC6347"/>, the ClientHello, ServerHello, and
          Certificate messages are all sent in cleartext. This check is not
          possible with (D)TLS 1.3, which encrypts the Certificate message and
          therefore hides the server identity from any intermediary. In (D)TLS
          1.3, the server certificate validation functions should be executed
          within an on-path (D)TLS proxy if such a proxy exists.</t>
        </li>
        <li pn="section-1-5.3">
          <t indent="0" pn="section-1-5.3.1">Support new communication patterns. An IoT device can learn a new
          capability, and the new capability can change the way the IoT device
          communicates with other devices located in the local network and the
          Internet. There would be an inaccurate policy if an IoT device
          rapidly changes the IP addresses and domain names it communicates
          with while the MUD ACLs were slower to update (see <xref target="CLEAR-AS-MUD" format="default" sectionFormat="of" derivedContent="CLEAR-AS-MUD"/>). In such a case, observable (D)TLS
          profile parameters can be used to permit intended use and block
          malicious behavior from the IoT device.</t>
        </li>
      </ul>
      <t indent="0" pn="section-1-6">The YANG module specified in <xref target="YANG2" format="default" sectionFormat="of" derivedContent="Section 5.2"/> of this
      document is an extension of "YANG Data Model for Network Access Control
      Lists (ACLs)" <xref target="RFC8519" format="default" sectionFormat="of" derivedContent="RFC8519"/> to enhance MUD <xref target="RFC8520" format="default" sectionFormat="of" derivedContent="RFC8520"/> to model observable (D)TLS profile parameters.
      Using these (D)TLS profile parameters, an active MUD-enforcing network
      security service (e.g., firewall) can identify MUD non-compliant (D)TLS
      behavior indicating outdated cryptography or malware. This detection can
      prevent malware downloads, block access to malicious domains, enforce
      use of strong ciphers, stop data exfiltration, etc. In addition,
      organizations may have policies around acceptable ciphers and
      certificates for the websites the IoT devices connect to. Examples
      include no use of old and less secure versions of TLS, no use of
      self-signed certificates, deny-list or accept-list of Certificate
      Authorities, valid certificate expiration time, etc. These policies can
      be enforced by observing the (D)TLS profile parameters. Network security
      services can use the IoT device's (D)TLS profile parameters to identify
      legitimate flows by observing (D)TLS sessions, and can make inferences
      to permit legitimate flows and block malicious or insecure flows.
      Additionally, it supports network communications adherence to security
      policies by ensuring that TLS certificates are valid and deprecated
      cipher suites are avoided. The proposed technique is also suitable in
      deployments where decryption techniques are not ideal due to privacy
      concerns, non-cooperating endpoints, and expense.</t>
    </section>
    <section anchor="notation" numbered="true" toc="include" removeInRFC="false" pn="section-2">
      <name slugifiedName="name-terminology">Terminology</name>
      <t indent="0" pn="section-2-1">
    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 <xref target="RFC2119" format="default" sectionFormat="of" derivedContent="RFC2119"/> <xref target="RFC8174" format="default" sectionFormat="of" derivedContent="RFC8174"/> 
    when, and only when, they appear in all capitals, as shown here.
      </t>
      <dl newline="false" spacing="normal" indent="3" pn="section-2-2">
        <dt pn="section-2-2.1">(D)TLS:</dt>
        <dd pn="section-2-2.2">Used for statements that apply to both
	  Transport Layer Security <xref target="RFC8446" format="default" sectionFormat="of" derivedContent="RFC8446"/>
	  and Datagram Transport Layer Security <xref target="RFC6347" format="default" sectionFormat="of" derivedContent="RFC6347"/>. Specific terms "TLS" and "DTLS" are used for any
	  statement that applies to either protocol alone.</dd>
        <dt pn="section-2-2.3">DoH/DoT:</dt>
        <dd pn="section-2-2.4">Refers to DNS-over-HTTPS <xref target="RFC8484" format="default" sectionFormat="of" derivedContent="RFC8484"/> and/or DNS-over-TLS <xref target="RFC7858" format="default" sectionFormat="of" derivedContent="RFC7858"/>.</dd>
        <dt pn="section-2-2.5">Middlebox:</dt>
        <dd pn="section-2-2.6">A middlebox that interacts with TLS traffic
	  can either act as a TLS proxy, intercepting and decrypting the
	  traffic for inspection, or inspect the traffic between TLS peers
	  without terminating the TLS session.</dd>
        <dt pn="section-2-2.7">Endpoint Security Agent:</dt>
        <dd pn="section-2-2.8">An Endpoint Security Agent is a
	  software installed on endpoint devices that protects them from
	  security threats.  It provides features such as malware protection,
	  firewall, and intrusion prevention to ensure the device's security
	  and integrity.</dd>
        <dt pn="section-2-2.9">Network Security Service:</dt>
        <dd pn="section-2-2.10">A Network Security Service
	  refers to a set of mechanisms designed to protect network
	  communications and resources from attacks.</dd>
      </dl>
    </section>
    <section numbered="true" toc="include" removeInRFC="false" pn="section-3">
      <name slugifiedName="name-overview-of-mud-dtls-profil">Overview of MUD (D)TLS Profiles for IoT devices</name>
      <t indent="0" pn="section-3-1">In Enterprise networks, protection and detection are typically done
      both on end hosts and in the network. Endpoint security agents have deep
      visibility on the devices where they are installed, whereas the network
      has broader visibility. Installing endpoint security agents may not be a
      viable option on IoT devices, and network security service is an
      efficient means to protect such IoT devices. If the IoT device supports
      a MUD (D)TLS profile, the (D)TLS profile parameters of the IoT device
      can be used by a middlebox to detect and block malware communication,
      while at the same time preserving the privacy of legitimate uses of
      encryption. In addition, it enforces organizational security policies,
      ensuring that devices comply. By monitoring (D)TLS parameters, network
      administrators can identify and mitigate the use of outdated TLS
      versions, cryptographic algorithms, and non-compliant certificates. The
      middlebox need not proxy (D)TLS, but can passively observe the parameters
      of (D)TLS handshakes from IoT devices and gain visibility into TLS 1.2
      parameters and partial visibility into TLS 1.3 parameters.</t>
      <t indent="0" pn="section-3-2">Malicious agents can try to use the (D)TLS profile parameters of
      legitimate agents to evade detection, but it becomes a challenge to
      mimic the behavior of various IoT device types and IoT device models
      from several manufacturers. In other words, malware developers will have
      to develop malicious agents per IoT device type, manufacturer and model,
      infect the device with the tailored malware agent, and will have keep up
      with updates to the device's (D)TLS profile parameters over time.
      Furthermore, the malware's command and control server certificates need
      to be signed by the same certifying authorities trusted by the IoT
      devices. Typically, IoT devices have an infrastructure that supports a
      rapid deployment of updates, and malware agents will have a
      near-impossible task of similarly deploying updates and continuing to
      mimic the TLS behavior of the IoT device it has infected.</t>
      <t indent="0" pn="section-3-3">However, if the IoT device has reached end-of-life (EOL) and the IoT
manufacturer will not issue a firmware or software update to the IoT device or
will not update the MUD file, the "is-supported" attribute defined in <xref target="RFC8520" sectionFormat="of" section="3.6" format="default" derivedLink="https://rfc-editor.org/rfc/rfc8520#section-3.6" derivedContent="RFC8520"/> can be used by the MUD manager to indicate that the IoT
manufacturer no longer supports the device. The EOL of a device, where the IoT
manufacturer no longer supports it, does not necessarily mean the device is
defective.  Instead, it signifies that the device is no longer receiving
updates, support, or security patches, which necessitates replacement and
upgrading to next-generation devices to ensure continued functionality,
security, and compatibility with modern networks. The network security service
will have to rely on other techniques discussed in <xref target="Security" format="default" sectionFormat="of" derivedContent="Section 9"/> to identify malicious connections until the device is
replaced.</t>
      <t indent="0" pn="section-3-4">Compromised IoT devices are typically used for launching DDoS
attacks (<xref target="RFC8576" sectionFormat="of" section="3" format="default" derivedLink="https://rfc-editor.org/rfc/rfc8576#section-3" derivedContent="RFC8576"/>). For
example, DDoS attacks like Slowloris <xref target="SLOWLORIS" format="default" sectionFormat="of" derivedContent="SLOWLORIS"/> and Transport Layer Security (TLS) re-negotiation can be
blocked if the victim's server certificate is not be signed by the same
certifying authorities trusted by the IoT device.</t>
    </section>
    <section numbered="true" toc="include" removeInRFC="false" pn="section-4">
      <name slugifiedName="name-dtls-13-handshake">(D)TLS 1.3 Handshake</name>
      <t indent="0" pn="section-4-1">In (D)TLS 1.3, full (D)TLS handshake inspection is not possible since
      all (D)TLS handshake messages excluding the ClientHello message are
      encrypted. (D)TLS 1.3 has introduced new extensions in the handshake
      record layers called Encrypted Extensions. When using these extensions,
      handshake messages will be encrypted and network security services (such
      as a firewall) are incapable of deciphering the handshake, and thus
      cannot view the server certificate. However, the ClientHello and
      ServerHello still have some fields visible, such as the list of
      supported versions, named groups, cipher suites, signature algorithms,
      extensions in ClientHello, and the chosen cipher in the ServerHello. For
      instance, if the malware uses evasion techniques like ClientHello
      randomization, the observable list of cipher suites and extensions
      offered by the malware agent in the ClientHello message will not match
      the list of cipher suites and extensions offered by the legitimate
      client in the ClientHello message, and the middlebox can block malicious
      flows without acting as a (D)TLS 1.3 proxy.</t>
      <section anchor="full" numbered="true" toc="include" removeInRFC="false" pn="section-4.1">
        <name slugifiedName="name-full-dtls-13-handshake-insp">Full (D)TLS 1.3 Handshake Inspection</name>
        <t indent="0" pn="section-4.1-1">To obtain more visibility into negotiated TLS 1.3 parameters, a
        middlebox can act as a (D)TLS 1.3 proxy. A middlebox can act as a
        (D)TLS proxy for the IoT devices owned and managed by the IT team in
        the Enterprise network and the (D)TLS proxy must meet the security and
        privacy requirements of the organization. In other words, the scope of
        a middlebox acting as a (D)TLS proxy is restricted to the Enterprise network
        owning and managing the IoT devices. The middlebox would have to
        follow the behavior detailed in <xref target="RFC8446" sectionFormat="of" section="9.3" format="default" derivedLink="https://rfc-editor.org/rfc/rfc8446#section-9.3" derivedContent="RFC8446"/> to act as a compliant (D)TLS 1.3 proxy.</t>
        <t indent="0" pn="section-4.1-2">To further increase privacy, the Encrypted Client Hello (ECH) extension
        <xref target="I-D.ietf-tls-esni" format="default" sectionFormat="of" derivedContent="TLS-ESNI"/> prevents passive observation
        of the TLS Server Name Indication extension and other potentially
        sensitive fields, such as the Application-Layer Protocol Negotiation (ALPN) <xref target="RFC7301" format="default" sectionFormat="of" derivedContent="RFC7301"/>. To
        effectively provide that privacy protection, the ECH extension needs to be
        used in conjunction with DNS encryption (e.g., DoH). A middlebox
        (e.g., firewall) passively inspecting the ECH extension cannot observe the
        encrypted SNI nor observe the encrypted DNS traffic. The middlebox
        acting as a (D)TLS 1.3 proxy that does not support the ECH extension will
        act as if it is connecting to the public name and follows the behavior
        discussed in <xref target="I-D.ietf-tls-esni" sectionFormat="of" section="6.1.6" format="default" derivedLink="https://datatracker.ietf.org/doc/html/draft-ietf-tls-esni-24#section-6.1.6" derivedContent="TLS-ESNI"/>
        to securely signal the client to disable ECH.</t>
      </section>
      <section numbered="true" toc="include" removeInRFC="false" pn="section-4.2">
        <name slugifiedName="name-encrypted-dns">Encrypted DNS</name>
        <t indent="0" pn="section-4.2-1">A common usage pattern for certain types of IoT devices (e.g.,
        light bulb) is for it to "call home" to a service that resides on the
        public Internet, where that service is referenced through a domain
        name (A or AAAA record). As discussed in "Manufacturer Usage
        Description Specification" <xref target="RFC8520" format="default" sectionFormat="of" derivedContent="RFC8520"/>,
        these devices tend to require access to very few sites. Thus, all
        other access should be considered suspect. This technique complements
        MUD policy enforcement at the TLS level by ensuring that DNS queries
        are monitored and filtered, thereby enhancing overall security. If an
        IoT device is pre-configured to use a DNS resolver not signaled by the
        network, the MUD policy enforcement point is moved to that resolver,
        which cannot enforce the MUD policy based on domain names (<xref target="RFC8520" sectionFormat="of" section="8" format="default" derivedLink="https://rfc-editor.org/rfc/rfc8520#section-8" derivedContent="RFC8520"/>). If the DNS query
        is not accessible for inspection, it becomes quite difficult for the
        infrastructure to detect any issues. Therefore, the use of a DNS
        resolver that is not signaled by the network is generally incompatible
        with MUD. A network-designated DoH/DoT server is necessary to allow
        MUD policy enforcement on the local network, for example, using the
        techniques specified in DNR <xref target="RFC9463" format="default" sectionFormat="of" derivedContent="RFC9463">
          </xref> and DDR <xref target="RFC9462" format="default" sectionFormat="of" derivedContent="RFC9462"/>.</t>
      </section>
    </section>
    <section anchor="YANG" numbered="true" toc="include" removeInRFC="false" pn="section-5">
      <name slugifiedName="name-dtls-profile-of-an-iot-devi">(D)TLS Profile of an IoT device</name>
      <t indent="0" pn="section-5-1">This document specifies a YANG module that represents the (D)TLS
      profile. This YANG module provides a means to characterize the (D)TLS
      traffic profile of a device. Network security services can use these
      profiles to permit conformant traffic or to deny traffic from devices
      that deviates from it. This module uses the cryptographic types defined
      in <xref target="RFC9640" format="default" sectionFormat="of" derivedContent="RFC9640"/>. See <xref target="RFC7925" format="default" sectionFormat="of" derivedContent="RFC7925"/> for (D)TLS 1.2 and <xref target="I-D.ietf-uta-tls13-iot-profile" format="default" sectionFormat="of" derivedContent="IoT-PROFILE"/> for DTLS 1.3
      recommendations related to IoT devices, and <xref target="RFC9325" format="default" sectionFormat="of" derivedContent="RFC9325"/> for additional (D)TLS 1.2 recommendations.</t>
      <t indent="0" pn="section-5-2">A companion YANG module is defined to include a collection of (D)TLS
      parameters and (D)TLS versions maintained by IANA: "iana-tls-profile"
      (<xref target="yang-iana" format="default" sectionFormat="of" derivedContent="Section 5.3"/>).</t>
      <t indent="0" pn="section-5-3">The (D)TLS parameters in each (D)TLS profile include the
      following:</t>
      <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-5-4">
        <li pn="section-5-4.1">
          <t indent="0" pn="section-5-4.1.1">Profile name</t>
        </li>
        <li pn="section-5-4.2">
          <t indent="0" pn="section-5-4.2.1">(D)TLS versions supported by the IoT device.</t>
        </li>
        <li pn="section-5-4.3">
          <t indent="0" pn="section-5-4.3.1">List of supported cipher suites (<xref target="RFC8446" sectionFormat="of" section="11" format="default" derivedLink="https://rfc-editor.org/rfc/rfc8446#section-11" derivedContent="RFC8446"/>). For (D)TLS 1.2, <xref target="RFC7925" format="default" sectionFormat="of" derivedContent="RFC7925"/> recommends Authenticated Encryption with Associated Data (AEAD) ciphers for IoT
          devices.</t>
        </li>
        <li pn="section-5-4.4">
          <t indent="0" pn="section-5-4.4.1">List of supported extension types.</t>
        </li>
        <li pn="section-5-4.5">
          <t indent="0" pn="section-5-4.5.1">List of trust anchor certificates used by the IoT device. If the
          server certificate is signed by one of the trust anchors, the
          middlebox continues with the connection as normal. Otherwise, the
          middlebox will react as if the server certificate validation has
          failed and takes appropriate action (e.g, blocks the (D)TLS session).
          An IoT device can use a private trust anchor to validate a server's
          certificate (e.g., the private trust anchor can be preloaded at
          manufacturing time on the IoT device and the IoT device fetches the
          firmware image from the firmware server whose certificate is signed
          by the private CA). This empowers the middlebox to reject TLS
          sessions to servers that the IoT device does not trust.</t>
        </li>
        <li pn="section-5-4.6">
          <t indent="0" pn="section-5-4.6.1">List of pre-shared key exchange modes.</t>
        </li>
        <li pn="section-5-4.7">
          <t indent="0" pn="section-5-4.7.1">List of named groups (DHE or ECDHE) supported by the client.</t>
        </li>
        <li pn="section-5-4.8">
          <t indent="0" pn="section-5-4.8.1">List of signature algorithms the client can validate in X.509
          server certificates.</t>
        </li>
        <li pn="section-5-4.9">
          <t indent="0" pn="section-5-4.9.1">List of signature algorithms the client is willing to accept for
          the CertificateVerify message (<xref target="RFC8446" sectionFormat="of" section="4.2.3" format="default" derivedLink="https://rfc-editor.org/rfc/rfc8446#section-4.2.3" derivedContent="RFC8446"/>). For example, a TLS client
          implementation can support different sets of algorithms for
          certificates, and it can signal the capabilities in the
          "signature_algorithms_cert" and "signature_algorithms"
          extensions.</t>
        </li>
        <li pn="section-5-4.10">
          <t indent="0" pn="section-5-4.10.1">List of supported application protocols (e.g., h3, h2, http/1.1
          etc.).</t>
        </li>
        <li pn="section-5-4.11">
          <t indent="0" pn="section-5-4.11.1">List of certificate compression algorithms (defined in <xref target="RFC8879" format="default" sectionFormat="of" derivedContent="RFC8879"/>).</t>
        </li>
        <li pn="section-5-4.12">
          <t indent="0" pn="section-5-4.12.1">List of the distinguished names <xref target="X501" format="default" sectionFormat="of" derivedContent="X501"/> of
          acceptable certificate authorities, represented in DER-encoded
          format <xref target="X690" format="default" sectionFormat="of" derivedContent="X690"> </xref> (defined in <xref target="RFC8446" sectionFormat="of" section="4.2.4" format="default" derivedLink="https://rfc-editor.org/rfc/rfc8446#section-4.2.4" derivedContent="RFC8446"/>).</t>
        </li>
      </ul>
      <t indent="0" pn="section-5-5"><xref target="RFC8701" format="default" sectionFormat="of" derivedContent="RFC8701">GREASE</xref> defines a mechanism for TLS
      peers to send random values on TLS parameters to ensure future
      extensibility of TLS extensions. Similar random values might be extended
      to other TLS parameters. Thus, the (D)TLS profile parameters defined in
      the YANG module by this document <bcp14>MUST NOT</bcp14> include the GREASE values for
      extension types, named groups, signature algorithms, (D)TLS versions,
      pre-shared key exchange modes, cipher suites, and any other TLS
      parameters defined in future RFCs.</t>
      <t indent="0" pn="section-5-6">The (D)TLS profile does not include parameters like compression
      methods for data compression. <xref target="RFC9325" format="default" sectionFormat="of" derivedContent="RFC9325"/> recommends
      disabling TLS-level compression to prevent compression-related attacks.
      In TLS 1.3, only the "null" compression method is allowed (<xref target="RFC8446" sectionFormat="of" section="4.1.2" format="default" derivedLink="https://rfc-editor.org/rfc/rfc8446#section-4.1.2" derivedContent="RFC8446"/>).</t>
      <section numbered="true" toc="include" removeInRFC="false" pn="section-5.1">
        <name slugifiedName="name-tree-structure-of-the-dtls-">Tree Structure of the (D)TLS Profile Extension to the ACL YANG Module</name>
        <t indent="0" pn="section-5.1-1">This document augments the "ietf-acl" ACL YANG module defined in
        <xref target="RFC8519" format="default" sectionFormat="of" derivedContent="RFC8519"/> for signaling the IoT device (D)TLS
        profile. This document defines the YANG module "ietf-acl-tls". The
        meaning of the symbols in the YANG tree diagram are defined in <xref target="RFC8340" format="default" sectionFormat="of" derivedContent="RFC8340"/> and it has the following tree structure:</t>
        <sourcecode name="" type="yangtree" markers="false" pn="section-5.1-2">
module: ietf-acl-tls
  augment /acl:acls/acl:acl/acl:aces/acl:ace/acl:matches:
    +--rw client-profiles {match-on-tls-dtls}?
       +--rw tls-dtls-profile* [name]
          +--rw name                           string
          +--rw supported-tls-version*        ianatp:tls-version
          +--rw supported-dtls-version*       ianatp:dtls-version
          +--rw cipher-suite*                 ianatp:cipher-algorithm
          +--rw extension-type*
          |       ianatp:extension-type
          +--rw accept-list-ta-cert*
          |       ct:trust-anchor-cert-cms
          +--rw psk-key-exchange-mode*
          |       ianatp:psk-key-exchange-mode
          |       {tls13 or dtls13}?
          +--rw supported-groups*
          |       ianatp:supported-group
          +--rw signature-algorithm-cert*
          |       ianatp:signature-algorithm
          |       {tls13 or dtls13}?
          +--rw signature-algorithm*
          |       ianatp:signature-algorithm
          +--rw application-protocol*
          |       ianatp:application-protocol
          +--rw cert-compression-algorithm*
          |       ianatp:cert-compression-algorithm
          |       {tls13 or dtls13}?
          +--rw certificate-authorities*
                  certificate-authority
                  {tls13 or dtls13}?
</sourcecode>
      </section>
      <section anchor="YANG2" numbered="true" toc="include" removeInRFC="false" pn="section-5.2">
        <name slugifiedName="name-the-dtls-profile-extension-">The (D)TLS Profile Extension to the ACL YANG Module</name>
        <sourcecode name="ietf-acl-tls@2025-04-18.yang" type="yang" markers="true" pn="section-5.2-1">
module ietf-acl-tls {
  yang-version 1.1;
  namespace "urn:ietf:params:xml:ns:yang:ietf-acl-tls";
  prefix acl-tls;

  import iana-tls-profile {
    prefix ianatp;
    reference
      "RFC 9761: Manufacturer Usage Description (MUD) for TLS and
                 DTLS Profiles for Internet of Things (IoT) Devices";
  }
  import ietf-crypto-types {
    prefix ct;
    reference
      "RFC 9640: YANG Data Types and Groupings for Cryptography";
  }
  import ietf-access-control-list {
    prefix acl;
    reference
      "RFC 8519: YANG Data Model for Network Access
                 Control Lists (ACLs)";
  }

  organization
    "IETF OPSAWG (Operations and Management Area Working Group)";
  contact
    "WG Web: &lt;https://datatracker.ietf.org/wg/opsawg/&gt;
     WG List: opsawg@ietf.org

     Author: Tirumaleswar Reddy.K
             kondtir@gmail.com

     Author: Dan Wing
             danwing@gmail.com

     Author: Blake Anderson
             blake.anderson@cisco.com

    ";
  description
    "This YANG module defines a component that augments the
     IETF description of an access list to allow (D)TLS profiles
     as matching criteria.

     Copyright (c) 2025 IETF Trust and the persons identified as
     authors of the code.  All rights reserved.

     Redistribution and use in source and binary forms, with or
     without modification, is permitted pursuant to, and subject
     to the license terms contained in, the Revised BSD License
     set forth in Section 4.c of the IETF Trust's Legal Provisions
     Relating to IETF Documents
     (http://trustee.ietf.org/license-info).

     This version of this YANG module is part of RFC 9761; see
     the RFC itself for full legal notices.";

  revision 2025-04-18 {
    description
      "Initial revision.";
    reference
      "RFC 9761: Manufacturer Usage Description (MUD) for TLS and
                 DTLS Profiles for Internet of Things (IoT) Devices";
  }

  feature tls12 {
    description
      "TLS Protocol Version 1.2 is supported.";
    reference
      "RFC 5246: The Transport Layer Security (TLS) Protocol
                 Version 1.2";
  }

  feature tls13 {
    description
      "TLS Protocol Version 1.3 is supported.";
    reference
      "RFC 8446: The Transport Layer Security (TLS) Protocol
                 Version 1.3";
  }

  feature dtls12 {
    description
      "DTLS Protocol Version 1.2 is supported.";
    reference
      "RFC 6347: Datagram Transport Layer Security
                 Version 1.2";
  }

  feature dtls13 {
    description
      "DTLS Protocol Version 1.3 is supported.";
    reference
      "RFC 9147: Datagram Transport Layer Security 1.3";
  }

  feature match-on-tls-dtls {
    description
      "The networking device can support matching on
       (D)TLS parameters.";
  }

  typedef spki-pin-set {
    type binary;
    description
      "Subject Public Key Info pin set as discussed in
       Section 2.4 of RFC 7469.";
  }

  typedef certificate-authority {
    type string;
    description
      "Distinguished Name of Certificate authority as discussed
       in Section 4.2.4 of RFC 8446.";
  }

  augment "/acl:acls/acl:acl/acl:aces/acl:ace/acl:matches" {
    if-feature "match-on-tls-dtls";
    description
      "(D)TLS specific matches.";
    container client-profiles {
      description
        "A grouping for (D)TLS profiles.";
      list tls-dtls-profile {
        key "name";
        description
          "A list of (D)TLS version profiles supported by
           the client.";
        leaf name {
          type string {
            length "1..64";
          }
          description
            "The name of (D)TLS profile; space and special
             characters are not allowed.";
        }
        leaf-list supported-tls-version {
          type ianatp:tls-version;
          description
            "TLS versions supported by the client.";
        }
        leaf-list supported-dtls-version {
          type ianatp:dtls-version;
          description
            "DTLS versions supported by the client.";
        }
        leaf-list cipher-suite {
          type ianatp:cipher-algorithm;
          description
            "A list of cipher suites supported by the client.";
        }
        leaf-list extension-type {
          type ianatp:extension-type;
          description
            "A list of Extension Types supported by the client.";
        }
        leaf-list accept-list-ta-cert {
          type ct:trust-anchor-cert-cms;
          description
            "A list of trust anchor certificates used by the
             client.";
        }
        leaf-list psk-key-exchange-mode {
          if-feature "tls13 or dtls13";
          type ianatp:psk-key-exchange-mode;
          description
            "pre-shared key exchange modes.";
        }
        leaf-list supported-group {
          type ianatp:supported-group;
          description
            "A list of named groups supported by the client.";
        }
        leaf-list signature-algorithm-cert {
          if-feature "tls13 or dtls13";
          type ianatp:signature-algorithm;
          description
            "A list signature algorithms the client can validate
             in X.509 certificates.";
        }
        leaf-list signature-algorithm {
          type ianatp:signature-algorithm;
          description
            "A list signature algorithms the client can validate
             in the CertificateVerify message.";
        }
        leaf-list application-protocol {
          type ianatp:application-protocol;
          description
            "A list application protocols supported by the client.";
        }
        leaf-list cert-compression-algorithm {
          if-feature "tls13 or dtls13";
          type ianatp:cert-compression-algorithm;
          description
            "A list certificate compression algorithms
             supported by the client.";
        }
        leaf-list certificate-authorities {
          if-feature "tls13 or dtls13";
          type certificate-authority;
          description
            "A list of the distinguished names of certificate
             authorities acceptable to the client.";
        }
      }
    }
  }
}
</sourcecode>
      </section>
      <section anchor="yang-iana" numbered="true" toc="include" removeInRFC="false" pn="section-5.3">
        <name slugifiedName="name-iana-dtls-profile-yang-modu">IANA (D)TLS Profile YANG Module</name>
        <t indent="0" pn="section-5.3-1">The TLS and DTLS IANA registries are available from <eref target="https://www.iana.org/assignments/tls-parameters" brackets="angle"/>
        and <eref target="https://www.iana.org/assignments/tls-extensiontype-values" brackets="angle"/>.
        Changes to TLS- and DTLS-related IANA registries are discussed in <xref target="RFC8447" format="default" sectionFormat="of" derivedContent="RFC8447"/>.</t>
        <t indent="0" pn="section-5.3-2">The values for all the parameters in the "iana-tls-profile" YANG
        module are defined in the TLS and DTLS IANA registries excluding the
        tls-version, dtls-version, spki-pin-set, and certificate-authority
        parameters. The values of spki-pin-set and certificate-authority
        parameters will be specific to the IoT device.</t>
        <t indent="0" pn="section-5.3-3">The TLS and DTLS IANA registries do not maintain (D)TLS version
        numbers. In (D)TLS 1.2 and below, the "legacy_version" field in the
        ClientHello message is used for version negotiation. However, in
        (D)TLS 1.3, the "supported_versions" extension is used by the client
        to indicate which versions of (D)TLS it supports. TLS 1.3 ClientHello
        messages are identified as having a "legacy_version" of 0x0303 and a
        "supported_versions" extension present with 0x0304 as the highest
        version. DTLS 1.3 ClientHello messages are identified as having a
        "legacy_version" of 0xfefd and a "supported_versions" extension
        present with 0x0304 as the highest version.</t>
        <t indent="0" pn="section-5.3-4">In order to ease updating the "iana-tls-profile" YANG module with
        future (D)TLS versions, new (D)TLS version registries are defined in
        <xref target="tls-registry" format="default" sectionFormat="of" derivedContent="Section 11.3"/> and <xref target="dtls-registry" format="default" sectionFormat="of" derivedContent="Section 11.4"/>. Whenever a new (D)TLS protocol version
        is defined, the registry will be updated using expert review; the
        "iana-tls-profile" YANG module will be automatically updated by
        IANA.</t>
        <t indent="0" pn="section-5.3-5">Implementers or users of this specification must refer to the
        IANA-maintained "iana-tls-profile" YANG module available at <eref target="https://www.iana.org/assignments/yang-parameters" brackets="angle"/>.</t>
        <t indent="0" pn="section-5.3-6">The initial version of the "iana-tls-profile" YANG module is
        defined as follows:</t>
        <sourcecode name="iana-tls-profile@2025-04-18.yang" type="yang" markers="true" pn="section-5.3-7">
module iana-tls-profile {
  yang-version 1.1;
  namespace "urn:ietf:params:xml:ns:yang:iana-tls-profile";
  prefix ianatp;

  organization
    "IANA";
  contact
    "        Internet Assigned Numbers Authority

     Postal: ICANN
             12025 Waterfront Drive, Suite 300
             Los Angeles, CA  90094-2536
             United States

     Tel:    +1 310 301 5800
     Email:  iana@iana.org&gt;";
  description
    "This module contains the YANG definition for the (D)TLS profile.

     Copyright (c) 2025 IETF Trust and the persons identified as
     authors of the code.  All rights reserved.

     Redistribution and use in source and binary forms, with or
     without modification, is permitted pursuant to, and subject
     to the license terms contained in, the Revised BSD License
     set forth in Section 4.c of the IETF Trust's Legal Provisions
     Relating to IETF Documents
     (http://trustee.ietf.org/license-info).

     All revisions of IETF and IANA published modules can be found
     at the YANG Parameters registry
     (https://www.iana.org/assignments/yang-parameters).

     The initial version of this YANG module is part of RFC 9761;
     see the RFC itself for full legal notices.

     The latest version of this YANG module is available at
     https://www.iana.org/assignments/yang-parameters.";

  revision 2025-04-18 {
    description
      "Initial revision.";
    reference
      "RFC 9761: Manufacturer Usage Description (MUD) for TLS and
                 DTLS Profiles for Internet of Things (IoT) Devices";
  }

  typedef extension-type {
    type uint16;
    description
      "Extension type in the TLS ExtensionType Values registry as
       defined in Section 7 of RFC 8447.";
  }

  typedef supported-group {
    type uint16;
    description
      "Supported Group in the TLS Supported Groups registry as
       defined in Section 9 of RFC 8447.";
  }

  typedef signature-algorithm {
    type uint16;
    description
      "Signature algorithm in the TLS SignatureScheme registry as
       defined in Section 11 of RFC 8446.";
  }

  typedef psk-key-exchange-mode {
    type uint8;
    description
      "Pre-shared key exchange mode in the TLS PskKeyExchangeMode
       registry as defined in Section 11 of RFC 8446.";
  }

  typedef application-protocol {
    type string;
    description
      "Application-Layer Protocol Negotiation (ALPN) Protocol ID
       registry as defined in Section 6 of RFC 7301.";
  }

  typedef cert-compression-algorithm {
    type uint16;
    description
      "Certificate compression algorithm in TLS Certificate
       Compression Algorithm IDs registry as defined in
       Section 7.3 of RFC 8879.";
  }

  typedef cipher-algorithm {
    type uint16;
    description
      "Cipher suite in TLS Cipher Suites registry
       as discussed in Section 11 of RFC 8446.";
  }

  typedef tls-version {
    type enumeration {
      enum tls12 {
        value 1;
        description
          "TLS Protocol Version 1.2.

           TLS 1.2 ClientHello contains
           0x0303 in 'legacy_version'.";
        reference
          "RFC 5246: The Transport Layer Security (TLS) Protocol
                     Version 1.2";
      }
      enum tls13 {
        value 2;
        description
          "TLS Protocol Version 1.3.

           TLS 1.3 ClientHello contains a
           supported_versions extension with 0x0304
           contained in its body and the ClientHello contains
           0x0303 in 'legacy_version'.";
        reference
          "RFC 8446: The Transport Layer Security (TLS) Protocol
                     Version 1.3";
      }
    }
    description
      "Indicates the TLS version.";
  }

  typedef dtls-version {
    type enumeration {
      enum dtls12 {
        value 1;
        description
          "DTLS Protocol Version 1.2.

           DTLS 1.2 ClientHello contains
           0xfefd in 'legacy_version'.";
        reference
          "RFC 6347: Datagram Transport Layer Security 1.2";
      }
      enum dtls13 {
        value 2;
        description
          "DTLS Protocol Version 1.3.

           DTLS 1.3 ClientHello contains a
           supported_versions extension with 0x0304
           contained in its body and the ClientHello contains
           0xfefd in 'legacy_version'.";
        reference
          "RFC 9147: Datagram Transport Layer Security 1.3";
      }
    }
    description
      "Indicates the DTLS version.";
  }
}
</sourcecode>
      </section>
      <section anchor="mud-dtls-extension" numbered="true" toc="include" removeInRFC="false" pn="section-5.4">
        <name slugifiedName="name-mud-dtls-profile-extension">MUD (D)TLS Profile Extension</name>
        <t indent="0" pn="section-5.4-1">This document augments the "ietf-mud" MUD YANG module to indicate
        whether the device supports (D)TLS profile. If the "ietf-mud-tls"
        extension is supported by the device, MUD file is assumed to implement
        the "match-on-tls-dtls" ACL model feature defined in this
        specification. Furthermore, only "accept" or "drop" actions <bcp14>SHOULD</bcp14> be
        included with the (D)TLS profile similar to the actions allowed in
        <xref target="RFC8520" sectionFormat="of" section="2" format="default" derivedLink="https://rfc-editor.org/rfc/rfc8520#section-2" derivedContent="RFC8520"/>.</t>
        <t indent="0" pn="section-5.4-2">This document defines the YANG module "ietf-mud-tls", which has the
        following tree structure:</t>
        <sourcecode name="" type="yangtree" markers="false" pn="section-5.4-3">
module: ietf-mud-tls
  augment /ietf-mud:mud:
    +--rw is-tls-dtls-profile-supported?   boolean
</sourcecode>
        <t indent="0" pn="section-5.4-4">The model is defined as follows:</t>
        <sourcecode name="ietf-mud-tls@2025-04-18.yang" type="yang" markers="true" pn="section-5.4-5">
module ietf-mud-tls {
  yang-version 1.1;
  namespace "urn:ietf:params:xml:ns:yang:ietf-mud-tls";
  prefix ietf-mud-tls;

  import ietf-mud {
    prefix ietf-mud;
    reference
      "RFC 8520: Manufacturer Usage Description Specification";
  }

  organization
    "IETF OPSAWG (Operations and Management Area Working Group)";
  contact
    "WG Web: &lt;https://datatracker.ietf.org/wg/opsawg/&gt;
     WG List: opsawg@ietf.org

     Author: Tirumaleswar Reddy.K
             kondtir@gmail.com

     Author: Dan Wing
             danwing@gmail.com

     Author: Blake Anderson
             blake.anderson@cisco.com

    ";
  description
    "Extension to a MUD module to indicate (D)TLS
     profile support.

     Copyright (c) 2025 IETF Trust and the persons identified as
     authors of the code.  All rights reserved.

     Redistribution and use in source and binary forms, with or
     without modification, is permitted pursuant to, and subject
     to the license terms contained in, the Revised BSD License
     set forth in Section 4.c of the IETF Trust's Legal Provisions
     Relating to IETF Documents
     (http://trustee.ietf.org/license-info).

     This version of this YANG module is part of RFC 9761; see
     the RFC itself for full legal notices.";

  revision 2025-04-18 {
    description
      "Initial revision.";
    reference
      "RFC 9761: Manufacturer Usage Description (MUD) for TLS and
                 DTLS Profiles for Internet of Things (IoT)
                 Devices";
  }

  augment "/ietf-mud:mud" {
    description
      "This adds an extension for a manufacturer
       to indicate whether the (D)TLS profile is
       supported by a device.";
    leaf is-tls-dtls-profile-supported {
      type boolean;
      default "false";
      description
        "This value will equal 'true' if a device supports
         (D)TLS profile.";
    }
  }
}
</sourcecode>
      </section>
    </section>
    <section anchor="processing" numbered="true" toc="include" removeInRFC="false" pn="section-6">
      <name slugifiedName="name-processing-of-the-mud-dtls-">Processing of the MUD (D)TLS Profile</name>
      <t indent="0" pn="section-6-1">The following text outlines the rules for a network security service
      (e.g., firewall) to follow to process the MUD (D)TLS Profile so as to
      avoid ossification:</t>
      <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-6-2">
        <li pn="section-6-2.1">
          <t indent="0" pn="section-6-2.1.1">If the (D)TLS parameter observed in a (D)TLS session is not
          specified in the MUD (D)TLS profile and the parameter is recognized
          by the firewall, it can identify unexpected (D)TLS usage, which can
          indicate the presence of unauthorized software or malware on an
          endpoint. The firewall can take several actions, such as blocking the
          (D)TLS session or raising an alert to quarantine and remediate the
          compromised device. For example, if the cipher suite
          TLS_RSA_WITH_AES_128_CBC_SHA in the ClientHello message is not
          specified in the MUD (D)TLS profile and the cipher suite is
          recognized by the firewall, it can identify unexpected TLS
          usage.</t>
        </li>
        <li pn="section-6-2.2">
          <t indent="0" pn="section-6-2.2.1">If the (D)TLS parameter observed in a (D)TLS session is not
          specified in the MUD (D)TLS profile and the (D)TLS parameter is not
          recognized by the firewall, it can ignore the unrecognized parameter
          and the correct behavior is not to block the (D)TLS session. The
          behavior is functionally equivalent to the compliant TLS middlebox
          description in <xref target="RFC8446" sectionFormat="of" section="9.3" format="default" derivedLink="https://rfc-editor.org/rfc/rfc8446#section-9.3" derivedContent="RFC8446"/> to
          ignore all unrecognized cipher suites, extensions, and other
          parameters. For example, if the cipher suite
          TLS_CHACHA20_POLY1305_SHA256 in the ClientHello message is not
          specified in the MUD (D)TLS profile and the cipher suite is not
          recognized by the firewall, it can ignore the unrecognized cipher
          suite. This rule also ensures that the network security service will
          ignore the GREASE values advertised by TLS peers and interoperate
          with the implementations advertising GREASE values.</t>
        </li>
        <li pn="section-6-2.3">
          <t indent="0" pn="section-6-2.3.1">Deployments update at different rates, so an updated MUD (D)TLS
          profile may support newer parameters. If the firewall does not
          recognize the newer parameters, an alert should be triggered to the
          firewall vendor and the IoT device owner or administrator. A
          firewall must be readily updatable so that when new parameters in
          the MUD (D)TLS profile are discovered that are not recognized by the
          firewall, it can be updated quickly. Most importantly, if the
          firewall is not readily updatable, its protection efficacy to
          identify emerging malware will decrease with time. For example, if
          the cipher suite TLS_AES_128_CCM_8_SHA256 specified in the MUD
          (D)TLS profile is not recognized by the firewall, an alert will be
          triggered. Similarly, if the (D)TLS version specified in the MUD
          file is not recognized by the firewall, an alert will be
          triggered.</t>
        </li>
        <li pn="section-6-2.4">
          <t indent="0" pn="section-6-2.4.1">If the MUD (D)TLS profile includes any parameters that are
          susceptible to attacks (e.g., weaker cryptographic parameters), an
          alert <bcp14>MUST</bcp14> be triggered to the firewall vendor and the IoT device
          owner or administrator.</t>
        </li>
      </ul>
    </section>
    <section anchor="Example" numbered="true" toc="include" removeInRFC="false" pn="section-7">
      <name slugifiedName="name-mud-file-example">MUD File Example</name>
      <t indent="0" pn="section-7-1">The example below contains (D)TLS profile parameters for an IoT device
      used to reach servers listening on port 443 using TCP transport. JSON
      encoding of YANG-modeled data <xref target="RFC7951" format="default" sectionFormat="of" derivedContent="RFC7951"/> is used to
      illustrate the example.</t>
      <sourcecode name="" type="" markers="false" pn="section-7-2">{
   "ietf-mud:mud": {
     "mud-version": 1,
      "mud-url": "https://example.com/IoTDevice",
      "last-update": "2024-08-05T03:56:40.105+10:00",
      "cache-validity": 100,
      "extensions": [
           "ietf-mud-tls"
       ],
      "ietf-mud-tls:is-tls-dtls-profile-supported": "true",
      "is-supported": true,
      "systeminfo": "IoT device name",
      "from-device-policy": {
         "access-lists": {
           "access-list": [
             {
               "name": "mud-7500-profile"
             }
           ]
         }
      },
     "ietf-access-control-list:acls": {
       "acl": [
         {
           "name": "mud-7500-profile",
           "type": "ipv6-acl-type",
           "aces": {
             "ace": [
               {
                 "name": "cl0-frdev",
                 "matches": {
                   "ipv6": {
                     "protocol": 6
                   },
                   "tcp": {
                     "ietf-mud:direction-initiated": "from-device",
                     "destination-port": {
                       "operator": "eq",
                       "port": 443
                     }
                   },
                   "ietf-acl-tls:client-profile" : {
                     "tls-dtls-profiles" : [
                        {
                           "name" : "profile1",
                           "supported-tls-versions" : ["tls13"],
                           "cipher-suite" : [4865, 4866],
                           "extension-types" : [10,11,13,16,24],
                           "supported-groups" : [29]
                        }
                      ]
                   },
                   "actions": {
                      "forwarding": "accept"
                   }
               }
            }
          ]
         }
        }
       ]
     }
   }
}
</sourcecode>
      <t indent="0" pn="section-7-3">The following illustrates the example scenarios for processing the
      above profile:</t>
      <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-7-4">
        <li pn="section-7-4.1">
          <t indent="0" pn="section-7-4.1.1">If the extension type "encrypt_then_mac" (code point 22) <xref target="RFC7366" format="default" sectionFormat="of" derivedContent="RFC7366"/> in the ClientHello message is recognized by
          the firewall, it can identify unexpected TLS usage.</t>
        </li>
        <li pn="section-7-4.2">
          <t indent="0" pn="section-7-4.2.1">If the extension type "token_binding" (code point 24) <xref target="RFC8472" format="default" sectionFormat="of" derivedContent="RFC8472"/> in the MUD (D)TLS profile is not recognized
          by the firewall, it can ignore the unrecognized extension. Because
          the extension type "token_binding" is specified in the profile, an
          alert will be triggered to the firewall vendor and the IoT device
          owner or administrator to notify the firewall is not up-to-date.</t>
        </li>
        <li pn="section-7-4.3">
          <t indent="0" pn="section-7-4.3.1">The two-byte values assigned by IANA for the cipher suites
          TLS_AES_128_GCM_SHA256 and TLS_AES_256_GCM_SHA384 are represented in
          decimal format.</t>
        </li>
      </ul>
    </section>
    <section anchor="ACL" numbered="true" toc="include" removeInRFC="false" pn="section-8">
      <name slugifiedName="name-software-based-acls-and-acl">Software-Based ACLs and ACLs Within a (D)TLS 1.3 Proxy</name>
      <t indent="0" pn="section-8-1">While ACL technology is traditionally associated with fixed-length
      bit matching in hardware implementations, such as those found in Ternary Content-Addressable Memory (TCAM),
      the use of ACLs in software, like with iptables, allows for more
      flexible matching criteria, including string matching. In the context of
      MUD (D)TLS profiles, the ability to match binary data and strings is a
      deliberate choice made to leverage the capabilities of software-based
      ACLs. This enables more dynamic and context-sensitive access control,
      which is essential for the intended application of MUD. The DNS
      extension added to ACL in the MUD specification <xref target="RFC8520" format="default" sectionFormat="of" derivedContent="RFC8520"/> also requires software-based ACLs.</t>
      <t indent="0" pn="section-8-2">Regarding the use of MUD (D)TLS ACL in a (D)TLS 1.3 proxy, the goal
      is for the proxy to intercept the (D)TLS handshake before applying any
      ACL rules. This implies that MUD (D)TLS ACL matching would need to occur
      after decrypting the encrypted TLS handshake messages within the proxy.
      The proxy would inspect the handshake fields according to the MUD
      profile. 

ACL matching would be performed in two stages: first, by filtering clear-text
TLS handshake message and second, by filtering after decrypting the TLS
handshake messages.</t>
    </section>
    <section anchor="Security" numbered="true" toc="include" removeInRFC="false" pn="section-9">
      <name slugifiedName="name-security-considerations">Security Considerations</name>
      <t indent="0" pn="section-9-1">Security considerations in <xref target="RFC8520" format="default" sectionFormat="of" derivedContent="RFC8520"/> need to be
      taken into consideration. The middlebox <bcp14>MUST</bcp14> adhere to the invariants
      discussed in <xref target="RFC8446" sectionFormat="of" section="9.3" format="default" derivedLink="https://rfc-editor.org/rfc/rfc8446#section-9.3" derivedContent="RFC8446"/> to act as a
      compliant proxy.</t>
      <t indent="0" pn="section-9-2">Although it is challenging for malware to mimic the TLS behavior of
      various IoT device types and models from different manufacturers, there
      is still a potential for malicious agents to use similar (D)TLS profile
      parameters as legitimate devices to evade detection. This difficulty
      arises because IoT devices often have distinct (D)TLS profiles between
      models and especially between manufacturers. While malware may find it
      hard to perfectly replicate the TLS behavior across such diverse
      devices, it is not impossible. Malicious agents might manage to use
      (D)TLS profile parameters that resemble those of legitimate devices. The
      feasibility of this depends on the nature of the profile parameters; for
      instance, parameters like certificate authorities are complex to mimic,
      while others, such as signature algorithms, may be easier to replicate.
      The difficulty in mimicking these profiles correlates with the
      specificity of the profiles and the variability in parameters used by
      different devices.</t>
      <t indent="0" pn="section-9-3">Network security services should also rely on contextual network data
      (e.g., domain name, IP address, etc.) to detect false negatives. For
      example, network security services filter malicious domain names and
      destination IP addresses with a bad reputation score. Furthermore, in order to
      detect such malicious flows, anomaly detection (deep learning techniques
      on network data) can be used to detect malicious agents using the same
      (D)TLS profile parameters as the legitimate agent on the IoT device. In
      anomaly detection, the main idea is to maintain rigorous learning of
      "normal" behavior and where an "anomaly" (or an attack) is identified
      and categorized based on the knowledge about the normal behavior and a
      deviation from this normal behavior. Network security vendors leverage
      TLS parameters and contextual network data to identify malware (for
      example, see <xref target="EVE" format="default" sectionFormat="of" derivedContent="EVE"/>).</t>
      <t indent="0" pn="section-9-4">The efficacy of identifying malware in (D)TLS 1.3 flows will be
      significantly reduced without leveraging contextual network data or
      acting as a proxy, as the encryption in (D)TLS 1.3 obscures many of the
      handshake details that could otherwise be used for detection.</t>
      <section numbered="true" toc="include" removeInRFC="false" pn="section-9.1">
        <name slugifiedName="name-challenges-in-mimicking-dtl">Challenges in Mimicking (D)TLS 1.2 Handshakes for IoT Devices</name>
        <t indent="0" pn="section-9.1-1">(D)TLS 1.2 generally does not require a proxy, as all fields in the
        (D)TLS profile are transmitted in cleartext during the handshake.
        While it is technically possible for an attacker to observe and mimic
        the handshake, an attacker would need to use a domain name and
        destination IP address with a good reputation, obtain certificates
        from the same CAs used by the IoT devices, and evade traffic analysis
        techniques (e.g., <xref target="EVE" format="default" sectionFormat="of" derivedContent="EVE"/>, which detects
        malicious patterns in encrypted traffic without decryption). This task
        is particularly challenging because IoT devices often have distinct
        (D)TLS profiles that vary between models and manufacturers. Unlike the
        developers of legitimate applications, malware authors are under
        additional constraints, such as avoiding any noticeable differences on
        the infected devices and the potential for take-down requests
        impacting their server infrastructure (e.g., certificate revocation by
        a CA upon reporting).</t>
      </section>
      <section numbered="true" toc="include" removeInRFC="false" pn="section-9.2">
        <name slugifiedName="name-considerations-for-the-iana">Considerations for the "iana-tls-profile" Module</name>
        <t indent="0" pn="section-9.2-1">This section follows the template defined in <xref target="I-D.ietf-netmod-rfc8407bis" sectionFormat="of" section="3.7.1" format="default" derivedLink="https://datatracker.ietf.org/doc/html/draft-ietf-netmod-rfc8407bis-23#section-3.7.1" derivedContent="YANG-GUIDELINES"/>.</t>
        <t indent="0" pn="section-9.2-2">The "iana-tls-profile" YANG module defines a data model that is designed to
be accessed via YANG-based management protocols, such as NETCONF <xref target="RFC6241" format="default" sectionFormat="of" derivedContent="RFC6241"/> and RESTCONF <xref target="RFC8040" format="default" sectionFormat="of" derivedContent="RFC8040"/>. These protocols have
to use a secure transport layer (e.g., SSH <xref target="RFC4252" format="default" sectionFormat="of" derivedContent="RFC4252"/>, TLS <xref target="RFC8446" format="default" sectionFormat="of" derivedContent="RFC8446"/>, and QUIC <xref target="RFC9000" format="default" sectionFormat="of" derivedContent="RFC9000"/>) and have to use mutual
authentication.</t>
        <t indent="0" pn="section-9.2-3">The Network Configuration Access Control Model (NACM) <xref target="RFC8341" format="default" sectionFormat="of" derivedContent="RFC8341"/>
provides the means to restrict access for particular NETCONF or
RESTCONF users to a preconfigured subset of all available NETCONF or
RESTCONF protocol operations and content.</t>
        <t indent="0" pn="section-9.2-4">There are no particularly sensitive writable data nodes.</t>
        <t indent="0" pn="section-9.2-5">There are no particularly sensitive readable data nodes.</t>
        <t indent="0" pn="section-9.2-6">This YANG module defines YANG enumerations for a public IANA-
        maintained registry.</t>
        <t indent="0" pn="section-9.2-7">YANG enumerations are not security-sensitive, as they are
        statically defined in the publicly accessible YANG module. IANA <bcp14>MAY</bcp14>
        deprecate and/or obsolete enumerations over time as needed to address
        security issues.</t>
        <t indent="0" pn="section-9.2-8">There are no particularly sensitive RPC or action operations.</t>
        <t indent="0" pn="section-9.2-9">The YANG module defines a set of identities, types, and
groupings. These nodes are intended to be reused by other YANG
modules. The module by itself does not expose any data nodes that
are writable, data nodes that contain read-only state, or RPCs.
As such, there are no additional security issues related to
the YANG module that need to be considered.</t>
      </section>
      <section numbered="true" toc="include" removeInRFC="false" pn="section-9.3">
        <name slugifiedName="name-considerations-for-the-ietf">Considerations for the "ietf-acl-tls" Module</name>
        <t indent="0" pn="section-9.3-1">This section follows the template defined in <xref target="I-D.ietf-netmod-rfc8407bis" sectionFormat="of" section="3.7.1" format="default" derivedLink="https://datatracker.ietf.org/doc/html/draft-ietf-netmod-rfc8407bis-23#section-3.7.1" derivedContent="YANG-GUIDELINES"/>.</t>
        <t indent="0" pn="section-9.3-2">The "ietf-acl-tls" YANG module defines a data model that is designed to be
accessed via YANG-based management protocols, such as NETCONF <xref target="RFC6241" format="default" sectionFormat="of" derivedContent="RFC6241"/> and RESTCONF <xref target="RFC8040" format="default" sectionFormat="of" derivedContent="RFC8040"/>. These protocols have
to use a secure transport layer (e.g., SSH <xref target="RFC4252" format="default" sectionFormat="of" derivedContent="RFC4252"/>, TLS <xref target="RFC8446" format="default" sectionFormat="of" derivedContent="RFC8446"/>, and QUIC <xref target="RFC9000" format="default" sectionFormat="of" derivedContent="RFC9000"/>) and have to use mutual
authentication.</t>
        <t indent="0" pn="section-9.3-3">The Network Configuration Access Control Model (NACM) <xref target="RFC8341" format="default" sectionFormat="of" derivedContent="RFC8341"/> provides the means to restrict access for particular
NETCONF or RESTCONF users to a preconfigured subset of all available NETCONF
or RESTCONF protocol operations and content.</t>
        <t indent="0" pn="section-9.3-4">There are a number of data nodes defined in this YANG module that are
writable/creatable/deletable (i.e., "config true", which is the
default). All writable data nodes are likely to be reasonably sensitive or
        vulnerable in some network environments. Write
operations (e.g., edit-config) and delete operations to these data
nodes without proper protection or authentication can have a negative
effect on network operations. For instance, the addition or
        removal of references to trusted anchors, (D)TLS versions, cipher
        suites, etc., can dramatically alter the implemented security
        policy. For this reason, the NACM extension "default-deny-write" has
        been set for all data nodes defined in this module.</t>
        <t indent="0" pn="section-9.3-5">Some of the readable data nodes defined in this YANG module may be
        considered sensitive or vulnerable in some network environments. It is
        thus important to control read access (e.g., via get, get-config, or
        notification) to these data nodes. The YANG module will provide
        insights into (D)TLS profiles of the IoT devices, and the privacy
        considerations discussed in <xref target="Privacy" format="default" sectionFormat="of" derivedContent="Section 10"/> need to be
        taken into account.</t>
        <t indent="0" pn="section-9.3-6">There are no particularly sensitive RPC or action operations.</t>
        <t indent="0" pn="section-9.3-7">This YANG module uses groupings from other YANG modules that define nodes
that may be considered sensitive or vulnerable in network environments. Refer
to the Security Considerations for dependent YANG modules for information as
to which nodes may be considered sensitive or vulnerable in network
environments.</t>
      </section>
      <section numbered="true" toc="include" removeInRFC="false" pn="section-9.4">
        <name slugifiedName="name-considerations-for-the-ietf-">Considerations for the "ietf-mud-tls" Module</name>
        <t indent="0" pn="section-9.4-1">This section follows the template defined in <xref target="I-D.ietf-netmod-rfc8407bis" sectionFormat="of" section="3.7.1" format="default" derivedLink="https://datatracker.ietf.org/doc/html/draft-ietf-netmod-rfc8407bis-23#section-3.7.1" derivedContent="YANG-GUIDELINES"/>.</t>
        <t indent="0" pn="section-9.4-2">The "ietf-mud-tls" YANG module defines a data model that is designed to be
 accessed via YANG-based management protocols, such as NETCONF <xref target="RFC6241" format="default" sectionFormat="of" derivedContent="RFC6241"/> and RESTCONF <xref target="RFC8040" format="default" sectionFormat="of" derivedContent="RFC8040"/>. These protocols
 have to use a secure transport layer (e.g., SSH <xref target="RFC4252" format="default" sectionFormat="of" derivedContent="RFC4252"/>, TLS
 <xref target="RFC8446" format="default" sectionFormat="of" derivedContent="RFC8446"/>, and QUIC <xref target="RFC9000" format="default" sectionFormat="of" derivedContent="RFC9000"/>) and have to use
 mutual authentication.</t>
        <t indent="0" pn="section-9.4-3">The Network Configuration Access Control Model (NACM) <xref target="RFC8341" format="default" sectionFormat="of" derivedContent="RFC8341"/> provides the means to restrict access for particular
NETCONF or RESTCONF users to a preconfigured subset of all available NETCONF
or RESTCONF protocol operations and content.</t>
        <t indent="0" pn="section-9.4-4">There are a number of data nodes defined in this YANG module that are
writable/creatable/deletable (i.e., "config true", which is the
default). All writable data nodes are likely to be reasonably sensitive or
        vulnerable in some network environments. Write
operations (e.g., edit-config) and delete operations to these data
nodes without proper protection or authentication can have a negative
effect on network operations. For instance, update that the
        device does not support (D)TLS profile can dramatically alter the
        implemented security policy. For this reason, the NACM extension
        "default-deny-write" has been set for all data nodes defined in this
        module.</t>
        <t indent="0" pn="section-9.4-5">There are no particularly sensitive RPC or action operations.</t>
        <t indent="0" pn="section-9.4-6">This YANG module uses groupings from other YANG modules that define nodes
that may be considered sensitive or vulnerable in network environments. Refer
to the Security Considerations for dependent YANG modules for information as
to which nodes may be considered sensitive or vulnerable in network
environments.</t>
      </section>
    </section>
    <section anchor="Privacy" numbered="true" toc="include" removeInRFC="false" pn="section-10">
      <name slugifiedName="name-privacy-considerations">Privacy Considerations</name>
      <t indent="0" pn="section-10-1">Privacy considerations discussed in <xref target="RFC8520" sectionFormat="of" section="16" format="default" derivedLink="https://rfc-editor.org/rfc/rfc8520#section-16" derivedContent="RFC8520"/> to not reveal the MUD URL to an attacker need
      to be taken into consideration. The MUD URL can be stored in a Trusted
      Execution Environment (TEE) for secure operation, enhanced data
      security, and prevention of exposure to unauthorized software. The MUD URL
      <bcp14>MUST</bcp14> be encrypted and shared only with the authorized components in the
      network (see Sections <xref target="RFC8520" sectionFormat="bare" section="1.5" format="default" derivedLink="https://rfc-editor.org/rfc/rfc8520#section-1.5" derivedContent="RFC8520"/> and <xref target="RFC8520" sectionFormat="bare" section="1.8" format="default" derivedLink="https://rfc-editor.org/rfc/rfc8520#section-1.8" derivedContent="RFC8520"/> of <xref target="RFC8520" format="default" sectionFormat="of" derivedContent="RFC8520"/>) so that an
      on-path attacker cannot read the MUD URL and identify the IoT device.
      Otherwise, it provides the attacker with guidance on what
      vulnerabilities may be present on the IoT device. Note that while
      protecting the MUD URL is valuable as described above, a compromised IoT
      device may be susceptible to malware performing vulnerability analysis
      (and version mapping) of the legitimate software located in memory or on
      non-volatile storage (e.g., disk, NVRAM). However, the malware on the
      IoT device is intended to be blocked from establishing a (D)TLS
      connection with the C&amp;C server to reveal this information because
      the connection would be blocked by the network security service
      supporting this specification.</t>
      <t indent="0" pn="section-10-2">Full handshake inspection (<xref target="full" format="default" sectionFormat="of" derivedContent="Section 4.1"/>) requires a
      (D)TLS proxy device that needs to decrypt traffic between the IoT
      device and its server(s). There is a tradeoff between privacy of the
      data carried inside (D)TLS (for example, personally identifiable
      information and protected health information especially) and efficacy of endpoint
      security. The use of (D)TLS proxies is <bcp14>NOT RECOMMENDED</bcp14> whenever
      possible. For example, an enterprise firewall administrator can
      configure the middlebox to bypass (D)TLS proxy functionality or payload
      inspection for connections destined to specific well-known services.
      Alternatively, an IoT device could be configured to reject all sessions
      that involve proxy servers to specific well-known services. In addition,
      mechanisms based on object security can be used by IoT devices to enable
      end-to-end security and the middlebox will not have any access to the
      packet data. For example, Object Security for Constrained RESTful
      Environments (OSCORE) <xref target="RFC8613" format="default" sectionFormat="of" derivedContent="RFC8613"/> is a proposal that
      protects Constrained Application Protocol (CoAP) messages by wrapping them in the CBOR Object Signing and Encryption (COSE) format <xref target="RFC9052" format="default" sectionFormat="of" derivedContent="RFC9052"/>.</t>
    </section>
    <section anchor="IANA" numbered="true" toc="include" removeInRFC="false" pn="section-11">
      <name slugifiedName="name-iana-considerations">IANA Considerations</name>
      <section numbered="true" toc="include" removeInRFC="false" pn="section-11.1">
        <name slugifiedName="name-dtls-profile-yang-modules">(D)TLS Profile YANG Modules</name>
        <t indent="0" pn="section-11.1-1">IANA has registered the following URIs in the
        "ns" subregistry within the "IETF XML Registry" <xref target="RFC3688" format="default" sectionFormat="of" derivedContent="RFC3688"/>: </t>
        <dl spacing="compact" newline="false" indent="3" pn="section-11.1-2">
          <dt pn="section-11.1-2.1">URI:</dt>
          <dd pn="section-11.1-2.2">urn:ietf:params:xml:ns:yang:iana-tls-profile</dd>
          <dt pn="section-11.1-2.3">Registrant Contact:</dt>
          <dd pn="section-11.1-2.4">IANA.</dd>
          <dt pn="section-11.1-2.5">XML:</dt>
          <dd pn="section-11.1-2.6">N/A; the requested URI is an XML namespace.</dd>
        </dl>
        <dl spacing="compact" newline="false" indent="3" pn="section-11.1-3">
          <dt pn="section-11.1-3.1">URI:</dt>
          <dd pn="section-11.1-3.2">urn:ietf:params:xml:ns:yang:ietf-acl-tls</dd>
          <dt pn="section-11.1-3.3">Registrant Contact:</dt>
          <dd pn="section-11.1-3.4">IESG.</dd>
          <dt pn="section-11.1-3.5">XML:</dt>
          <dd pn="section-11.1-3.6">N/A; the requested URI is an XML namespace.</dd>
        </dl>
        <dl spacing="compact" newline="false" indent="3" pn="section-11.1-4">
          <dt pn="section-11.1-4.1">URI:</dt>
          <dd pn="section-11.1-4.2">urn:ietf:params:xml:ns:yang:ietf-mud-tls</dd>
          <dt pn="section-11.1-4.3">Registrant Contact:</dt>
          <dd pn="section-11.1-4.4">IESG.</dd>
          <dt pn="section-11.1-4.5">XML:</dt>
          <dd pn="section-11.1-4.6">N/A; the requested URI is an XML namespace.</dd>
        </dl>
        <t indent="0" pn="section-11.1-5">IANA has created an IANA-maintained YANG module called
        "iana-tls-profile" based on the contents of <xref target="yang-iana" format="default" sectionFormat="of" derivedContent="Section 5.3"/>, which allows for new (D)TLS parameters
        and (D)TLS versions to be added to "client-profile".</t>
        <t indent="0" pn="section-11.1-6">IANA has registered the following YANG modules
        in the "YANG Module Names" registry <xref target="RFC6020" format="default" sectionFormat="of" derivedContent="RFC6020"/>
        of the "YANG Parameters" registry group.</t>
        <dl spacing="compact" newline="false" indent="3" pn="section-11.1-7">
          <dt pn="section-11.1-7.1">Name:</dt>
          <dd pn="section-11.1-7.2">iana-tls-profile</dd>
          <dt pn="section-11.1-7.3">Namespace:</dt>
          <dd pn="section-11.1-7.4">urn:ietf:params:xml:ns:yang:iana-tls-profile</dd>
          <dt pn="section-11.1-7.5">Maintained by IANA:</dt>
          <dd pn="section-11.1-7.6">Y</dd>
          <dt pn="section-11.1-7.7">Prefix:</dt>
          <dd pn="section-11.1-7.8">ianatp</dd>
          <dt pn="section-11.1-7.9">Reference:</dt>
          <dd pn="section-11.1-7.10">RFC 9761</dd>
        </dl>
        <dl spacing="compact" newline="false" indent="3" pn="section-11.1-8">
          <dt pn="section-11.1-8.1">Name:</dt>
          <dd pn="section-11.1-8.2">ietf-acl-tls</dd>
          <dt pn="section-11.1-8.3">Namespace:</dt>
          <dd pn="section-11.1-8.4">urn:ietf:params:xml:ns:yang:ietf-acl-tls</dd>
          <dt pn="section-11.1-8.5">Maintained by IANA:</dt>
          <dd pn="section-11.1-8.6">N</dd>
          <dt pn="section-11.1-8.7">Prefix:</dt>
          <dd pn="section-11.1-8.8">ietf-acl-tls</dd>
          <dt pn="section-11.1-8.9">Reference:</dt>
          <dd pn="section-11.1-8.10">RFC 9761</dd>
        </dl>
        <dl spacing="compact" newline="false" indent="3" pn="section-11.1-9">
          <dt pn="section-11.1-9.1">Name:</dt>
          <dd pn="section-11.1-9.2">ietf-mud-tls</dd>
          <dt pn="section-11.1-9.3">Namespace:</dt>
          <dd pn="section-11.1-9.4">urn:ietf:params:xml:ns:yang:ietf-mud-tls</dd>
          <dt pn="section-11.1-9.5">Maintained by IANA:</dt>
          <dd pn="section-11.1-9.6">N</dd>
          <dt pn="section-11.1-9.7">Prefix:</dt>
          <dd pn="section-11.1-9.8">ietf-mud-tls</dd>
          <dt pn="section-11.1-9.9">Reference:</dt>
          <dd pn="section-11.1-9.10">RFC 9761</dd>
        </dl>
      </section>
      <section anchor="iana-tls" numbered="true" toc="include" removeInRFC="false" pn="section-11.2">
        <name slugifiedName="name-considerations-for-the-iana-">Considerations for the iana-tls-profile Module</name>
        <t indent="0" pn="section-11.2-1">IANA has created the initial version of the
        IANA-maintained YANG module called "iana-tls-profile" based on the
        contents of <xref target="yang-iana" format="default" sectionFormat="of" derivedContent="Section 5.3"/>, which will allow for new
        (D)TLS parameters and (D)TLS versions to be added. IANA is requested
        to add this note:</t>
        <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-11.2-2">
          <li pn="section-11.2-2.1">
            <t indent="0" pn="section-11.2-2.1.1">tls-version and dtls-version values must not be directly added
            to the iana-tls-profile YANG module. Instead, they must be
            added to the "ACL TLS Version Codes" and "ACL DTLS
            Version Codes" registries (respectively), provided the new (D)TLS version has been
            standardized by the IETF. It allows a new (D)TLS version to be added
            to the "iana-tls-profile" YANG module.</t>
          </li>
          <li pn="section-11.2-2.2">
            <t indent="0" pn="section-11.2-2.2.1">(D)TLS parameters must not be directly added to the
            iana-tls-profile YANG module. They must instead be added to the
            "ACL (D)TLS Parameters" registry if the new (D)TLS parameters can
            be used by a middlebox to identify a MUD non-compliant (D)TLS
            behavior. It allows new (D)TLS parameters to be added to the
            "iana-tls-profile" YANG module.</t>
          </li>
        </ul>
        <t indent="0" pn="section-11.2-3">When a "tls-version" or "dtls-version" value is added
        to the "ACL TLS Version Codes" or "ACL DTLS Version Codes" registry (respectively), a
        new "enum" statement must be added to the iana-tls-profile YANG
        module. The following "enum" statement, and substatements thereof,
        should be defined:</t>
        <dl newline="false" spacing="normal" indent="15" pn="section-11.2-4">
          <dt pn="section-11.2-4.1">"enum":</dt>
          <dd pn="section-11.2-4.2">Replicates the label from the
            registry.</dd>
          <dt pn="section-11.2-4.3">"value":</dt>
          <dd pn="section-11.2-4.4">Contains the IANA-assigned value
            corresponding to the "tls-version" or "dtls-version".</dd>
          <dt pn="section-11.2-4.5">"description":</dt>
          <dd pn="section-11.2-4.6">Replicates the description
            from the registry.</dd>
          <dt pn="section-11.2-4.7">"reference":</dt>
          <dd pn="section-11.2-4.8">RFC YYYY: &lt;Title of the
            RFC&gt;, where YYYY is the RFC that added the
            "tls-version" or "dtls-version".</dd>
        </dl>
        <t indent="0" pn="section-11.2-5">When a (D)TLS parameter is added to the "ACL (D)TLS Parameters"
        registry, a new "type" statement must be added to the iana-tls-profile
        YANG module. The following "type" statement, and substatements
        thereof, should be defined:</t>
        <dl newline="false" spacing="normal" indent="15" pn="section-11.2-6">
          <dt pn="section-11.2-6.1">"derived type":</dt>
          <dd pn="section-11.2-6.2">Replicates the parameter
            name from the registry.</dd>
          <dt pn="section-11.2-6.3">"built-in type":</dt>
          <dd pn="section-11.2-6.4">Contains the built-in
            YANG type.</dd>
          <dt pn="section-11.2-6.5">"description":</dt>
          <dd pn="section-11.2-6.6">Replicates the description
            from the registry.</dd>
        </dl>
        <t indent="0" pn="section-11.2-7">When the iana-tls-profile YANG module is updated, a new "revision"
        statement must be added in front of the existing revision
        statements.</t>
        <t indent="0" pn="section-11.2-8">IANA has added this note to "ACL TLS Version Codes", "ACL
        DTLS Version Codes", and "ACL (D)TLS Parameters" registries:</t>
        <t indent="3" pn="section-11.2-9">When this registry is modified, the YANG module
            "iana-tls-profile" must be updated as defined in [RFC9761].</t>
      </section>
      <section anchor="tls-registry" numbered="true" toc="include" removeInRFC="false" pn="section-11.3">
        <name slugifiedName="name-acl-tls-version-registry">ACL TLS Version Registry</name>
        <t indent="0" pn="section-11.3-1">IANA has created a new registry titled "ACL TLS Version
        Codes". Codes in this registry are used as valid values of
        "tls-version" parameter. Further assignments are to be made through
        Expert Review <xref target="RFC8126" format="default" sectionFormat="of" derivedContent="RFC8126"/>. Experts must ensure that
        the TLS protocol version in a new registration is one that has been
        standardized by the IETF. It is expected that the registry will be
        updated infrequently, primarily when a new TLS version is standardized
        by the IETF.</t>
        <table align="center" pn="table-1">
          <name/>
          <thead>
            <tr>
              <th align="left" colspan="1" rowspan="1">Value</th>
              <th align="left" colspan="1" rowspan="1">Label</th>
              <th align="left" colspan="1" rowspan="1">Description</th>
              <th align="left" colspan="1" rowspan="1">Reference</th>
            </tr>
          </thead>
          <tbody>
            <tr>
              <td align="left" colspan="1" rowspan="1">1</td>
              <td align="left" colspan="1" rowspan="1">tls12</td>
              <td align="left" colspan="1" rowspan="1">TLS Version 1.2</td>
              <td align="left" colspan="1" rowspan="1">
                <xref target="RFC5246" format="default" sectionFormat="of" derivedContent="RFC5246"/></td>
            </tr>
            <tr>
              <td align="left" colspan="1" rowspan="1">2</td>
              <td align="left" colspan="1" rowspan="1">tls13</td>
              <td align="left" colspan="1" rowspan="1">TLS Version 1.3</td>
              <td align="left" colspan="1" rowspan="1">
                <xref target="RFC8446" format="default" sectionFormat="of" derivedContent="RFC8446"/></td>
            </tr>
          </tbody>
        </table>
      </section>
      <section anchor="dtls-registry" numbered="true" toc="include" removeInRFC="false" pn="section-11.4">
        <name slugifiedName="name-acl-dtls-version-registry">ACL DTLS Version Registry</name>
        <t indent="0" pn="section-11.4-1">IANA has created a new registry titled "ACL DTLS Version
        Codes". Codes in this registry are used as valid values of
        "dtls-version" parameter. Further assignments are to be made through
        Expert Review <xref target="RFC8126" format="default" sectionFormat="of" derivedContent="RFC8126"/>. Experts must ensure that
        the DTLS protocol version in a new registration is one that has been
        standardized by the IETF. It is expected that the registry will be
        updated infrequently, primarily when a new DTLS version is
        standardized by the IETF.</t>
        <table align="center" pn="table-2">
          <name/>
          <thead>
            <tr>
              <th align="left" colspan="1" rowspan="1">Value</th>
              <th align="left" colspan="1" rowspan="1">Label</th>
              <th align="left" colspan="1" rowspan="1">Description</th>
              <th align="left" colspan="1" rowspan="1">Reference</th>
            </tr>
          </thead>
          <tbody>
            <tr>
              <td align="left" colspan="1" rowspan="1">1</td>
              <td align="left" colspan="1" rowspan="1">dtls12</td>
              <td align="left" colspan="1" rowspan="1">DTLS Version 1.2</td>
              <td align="left" colspan="1" rowspan="1">
                <xref target="RFC6347" format="default" sectionFormat="of" derivedContent="RFC6347"/></td>
            </tr>
            <tr>
              <td align="left" colspan="1" rowspan="1">2</td>
              <td align="left" colspan="1" rowspan="1">dtls13</td>
              <td align="left" colspan="1" rowspan="1">DTLS Version 1.3</td>
              <td align="left" colspan="1" rowspan="1">
                <xref target="RFC9147" format="default" sectionFormat="of" derivedContent="RFC9147"/></td>
            </tr>
          </tbody>
        </table>
      </section>
      <section numbered="true" toc="include" removeInRFC="false" pn="section-11.5">
        <name slugifiedName="name-acl-dtls-parameters-registr">ACL (D)TLS Parameters Registry</name>
        <t indent="0" pn="section-11.5-1">IANA has created a new registry titled "ACL (D)TLS
        Parameters".</t>
        <t indent="0" pn="section-11.5-2">The values for all the (D)TLS parameters in the registry are
        defined in the TLS and DTLS IANA registries (<eref target="https://www.iana.org/assignments/tls-parameters/" brackets="none"/>
        and <eref target="https://www.iana.org/assignments/tls-extensiontype-values/" brackets="none"/>)
        excluding the tls-version and dtls-version parameters. Further
        assignments are to be made through Expert Review <xref target="RFC8126" format="default" sectionFormat="of" derivedContent="RFC8126"/>. Experts must ensure that the (D)TLS
        parameter in a new registration is one that has been standardized by
        the IETF. The registry is expected to be updated periodically,
        primarily when a new (D)TLS parameter is standardized by the IETF. The
        registry has been populated with the following initial parameters:</t>
        <table align="center" pn="table-3">
          <name/>
          <thead>
            <tr>
              <th align="left" colspan="1" rowspan="1">Parameter Name</th>
              <th align="left" colspan="1" rowspan="1">YANG Type</th>
              <th align="left" colspan="1" rowspan="1">JSON Type</th>
              <th align="left" colspan="1" rowspan="1">Description</th>
            </tr>
          </thead>
          <tbody>
            <tr>
              <td align="left" colspan="1" rowspan="1">extension-type</td>
              <td align="left" colspan="1" rowspan="1">uint16</td>
              <td align="left" colspan="1" rowspan="1">Number</td>
              <td align="left" colspan="1" rowspan="1">Extension type</td>
            </tr>
            <tr>
              <td align="left" colspan="1" rowspan="1">supported-group</td>
              <td align="left" colspan="1" rowspan="1">uint16</td>
              <td align="left" colspan="1" rowspan="1">Number</td>
              <td align="left" colspan="1" rowspan="1">Supported group</td>
            </tr>
            <tr>
              <td align="left" colspan="1" rowspan="1">signature-algorithm</td>
              <td align="left" colspan="1" rowspan="1">uint16</td>
              <td align="left" colspan="1" rowspan="1">Number</td>
              <td align="left" colspan="1" rowspan="1">Signature algorithm</td>
            </tr>
            <tr>
              <td align="left" colspan="1" rowspan="1">psk-key-exchange-mode</td>
              <td align="left" colspan="1" rowspan="1">uint8</td>
              <td align="left" colspan="1" rowspan="1">Number</td>
              <td align="left" colspan="1" rowspan="1">Pre-shared key exchange mode</td>
            </tr>
            <tr>
              <td align="left" colspan="1" rowspan="1">application-protocol</td>
              <td align="left" colspan="1" rowspan="1">string</td>
              <td align="left" colspan="1" rowspan="1">String</td>
              <td align="left" colspan="1" rowspan="1">Application protocol</td>
            </tr>
            <tr>
              <td align="left" colspan="1" rowspan="1">cert-compression-algorithm</td>
              <td align="left" colspan="1" rowspan="1">uint16</td>
              <td align="left" colspan="1" rowspan="1">Number</td>
              <td align="left" colspan="1" rowspan="1">Certificate compression algorithm</td>
            </tr>
            <tr>
              <td align="left" colspan="1" rowspan="1">cipher-algorithm</td>
              <td align="left" colspan="1" rowspan="1">uint16</td>
              <td align="left" colspan="1" rowspan="1">Number</td>
              <td align="left" colspan="1" rowspan="1">Cipher suite</td>
            </tr>
            <tr>
              <td align="left" colspan="1" rowspan="1">tls-version</td>
              <td align="left" colspan="1" rowspan="1">enumeration</td>
              <td align="left" colspan="1" rowspan="1">String</td>
              <td align="left" colspan="1" rowspan="1">TLS version</td>
            </tr>
            <tr>
              <td align="left" colspan="1" rowspan="1">dtls-version</td>
              <td align="left" colspan="1" rowspan="1">enumeration</td>
              <td align="left" colspan="1" rowspan="1">String</td>
              <td align="left" colspan="1" rowspan="1">DTLS version</td>
            </tr>
          </tbody>
        </table>
      </section>
      <section numbered="true" toc="include" removeInRFC="false" pn="section-11.6">
        <name slugifiedName="name-mud-extensions-registry">MUD Extensions Registry</name>
        <t indent="0" pn="section-11.6-1">IANA has created a new MUD Extension Name "ietf-mud-tls"
        in the "MUD Extensions" IANA registry <eref target="https://www.iana.org/assignments/mud" brackets="angle"/>.</t>
      </section>
    </section>
  </middle>
  <back>
    <displayreference target="I-D.ietf-tls-esni" to="TLS-ESNI"/>
    <displayreference target="I-D.ietf-uta-tls13-iot-profile" to="IoT-PROFILE"/>
    <displayreference target="I-D.ietf-netmod-rfc8407bis" to="YANG-GUIDELINES"/>
    <references pn="section-12">
      <name slugifiedName="name-references">References</name>
      <references pn="section-12.1">
        <name slugifiedName="name-normative-references">Normative References</name>
        <reference anchor="RFC2119" target="https://www.rfc-editor.org/info/rfc2119" quoteTitle="true" derivedAnchor="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 indent="0">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="RFC3688" target="https://www.rfc-editor.org/info/rfc3688" quoteTitle="true" derivedAnchor="RFC3688">
          <front>
            <title>The IETF XML Registry</title>
            <author fullname="M. Mealling" initials="M." surname="Mealling"/>
            <date month="January" year="2004"/>
            <abstract>
              <t indent="0">This document describes an IANA maintained registry for IETF standards which use Extensible Markup Language (XML) related items such as Namespaces, Document Type Declarations (DTDs), Schemas, and Resource Description Framework (RDF) Schemas.</t>
            </abstract>
          </front>
          <seriesInfo name="BCP" value="81"/>
          <seriesInfo name="RFC" value="3688"/>
          <seriesInfo name="DOI" value="10.17487/RFC3688"/>
        </reference>
        <reference anchor="RFC4252" target="https://www.rfc-editor.org/info/rfc4252" quoteTitle="true" derivedAnchor="RFC4252">
          <front>
            <title>The Secure Shell (SSH) Authentication Protocol</title>
            <author fullname="T. Ylonen" initials="T." surname="Ylonen"/>
            <author fullname="C. Lonvick" initials="C." role="editor" surname="Lonvick"/>
            <date month="January" year="2006"/>
            <abstract>
              <t indent="0">The Secure Shell Protocol (SSH) is a protocol for secure remote login and other secure network services over an insecure network. This document describes the SSH authentication protocol framework and public key, password, and host-based client authentication methods. Additional authentication methods are described in separate documents. The SSH authentication protocol runs on top of the SSH transport layer protocol and provides a single authenticated tunnel for the SSH connection protocol. [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="4252"/>
          <seriesInfo name="DOI" value="10.17487/RFC4252"/>
        </reference>
        <reference anchor="RFC5246" target="https://www.rfc-editor.org/info/rfc5246" quoteTitle="true" derivedAnchor="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 indent="0">This document specifies Version 1.2 of the Transport Layer Security (TLS) protocol. The TLS protocol provides communications security over the Internet. The protocol allows client/server applications to communicate in a way that is designed to prevent eavesdropping, tampering, or message forgery. [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="5246"/>
          <seriesInfo name="DOI" value="10.17487/RFC5246"/>
        </reference>
        <reference anchor="RFC6241" target="https://www.rfc-editor.org/info/rfc6241" quoteTitle="true" derivedAnchor="RFC6241">
          <front>
            <title>Network Configuration Protocol (NETCONF)</title>
            <author fullname="R. Enns" initials="R." role="editor" surname="Enns"/>
            <author fullname="M. Bjorklund" initials="M." role="editor" surname="Bjorklund"/>
            <author fullname="J. Schoenwaelder" initials="J." role="editor" surname="Schoenwaelder"/>
            <author fullname="A. Bierman" initials="A." role="editor" surname="Bierman"/>
            <date month="June" year="2011"/>
            <abstract>
              <t indent="0">The Network Configuration Protocol (NETCONF) defined in this document provides mechanisms to install, manipulate, and delete the configuration of network devices. It uses an Extensible Markup Language (XML)-based data encoding for the configuration data as well as the protocol messages. The NETCONF protocol operations are realized as remote procedure calls (RPCs). This document obsoletes RFC 4741. [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="6241"/>
          <seriesInfo name="DOI" value="10.17487/RFC6241"/>
        </reference>
        <reference anchor="RFC6347" target="https://www.rfc-editor.org/info/rfc6347" quoteTitle="true" derivedAnchor="RFC6347">
          <front>
            <title>Datagram Transport Layer Security Version 1.2</title>
            <author fullname="E. Rescorla" initials="E." surname="Rescorla"/>
            <author fullname="N. Modadugu" initials="N." surname="Modadugu"/>
            <date month="January" year="2012"/>
            <abstract>
              <t indent="0">This document specifies version 1.2 of the Datagram Transport Layer Security (DTLS) protocol. The DTLS protocol provides communications privacy for datagram protocols. The protocol allows client/server applications to communicate in a way that is designed to prevent eavesdropping, tampering, or message forgery. The DTLS protocol is based on the Transport Layer Security (TLS) protocol and provides equivalent security guarantees. Datagram semantics of the underlying transport are preserved by the DTLS protocol. This document updates DTLS 1.0 to work with TLS version 1.2. [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="6347"/>
          <seriesInfo name="DOI" value="10.17487/RFC6347"/>
        </reference>
        <reference anchor="RFC8040" target="https://www.rfc-editor.org/info/rfc8040" quoteTitle="true" derivedAnchor="RFC8040">
          <front>
            <title>RESTCONF Protocol</title>
            <author fullname="A. Bierman" initials="A." surname="Bierman"/>
            <author fullname="M. Bjorklund" initials="M." surname="Bjorklund"/>
            <author fullname="K. Watsen" initials="K." surname="Watsen"/>
            <date month="January" year="2017"/>
            <abstract>
              <t indent="0">This document describes an HTTP-based protocol that provides a programmatic interface for accessing data defined in YANG, using the datastore concepts defined in the Network Configuration Protocol (NETCONF).</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="8040"/>
          <seriesInfo name="DOI" value="10.17487/RFC8040"/>
        </reference>
        <reference anchor="RFC8174" target="https://www.rfc-editor.org/info/rfc8174" quoteTitle="true" derivedAnchor="RFC8174">
          <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 indent="0">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>
        <reference anchor="RFC8341" target="https://www.rfc-editor.org/info/rfc8341" quoteTitle="true" derivedAnchor="RFC8341">
          <front>
            <title>Network Configuration Access Control Model</title>
            <author fullname="A. Bierman" initials="A." surname="Bierman"/>
            <author fullname="M. Bjorklund" initials="M." surname="Bjorklund"/>
            <date month="March" year="2018"/>
            <abstract>
              <t indent="0">The standardization of network configuration interfaces for use with the Network Configuration Protocol (NETCONF) or the RESTCONF protocol requires a structured and secure operating environment that promotes human usability and multi-vendor interoperability. There is a need for standard mechanisms to restrict NETCONF or RESTCONF protocol access for particular users to a preconfigured subset of all available NETCONF or RESTCONF protocol operations and content. This document defines such an access control model.</t>
              <t indent="0">This document obsoletes RFC 6536.</t>
            </abstract>
          </front>
          <seriesInfo name="STD" value="91"/>
          <seriesInfo name="RFC" value="8341"/>
          <seriesInfo name="DOI" value="10.17487/RFC8341"/>
        </reference>
        <reference anchor="RFC8446" target="https://www.rfc-editor.org/info/rfc8446" quoteTitle="true" derivedAnchor="RFC8446">
          <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 indent="0">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 indent="0">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="RFC8519" target="https://www.rfc-editor.org/info/rfc8519" quoteTitle="true" derivedAnchor="RFC8519">
          <front>
            <title>YANG Data Model for Network Access Control Lists (ACLs)</title>
            <author fullname="M. Jethanandani" initials="M." surname="Jethanandani"/>
            <author fullname="S. Agarwal" initials="S." surname="Agarwal"/>
            <author fullname="L. Huang" initials="L." surname="Huang"/>
            <author fullname="D. Blair" initials="D." surname="Blair"/>
            <date month="March" year="2019"/>
            <abstract>
              <t indent="0">This document defines a data model for Access Control Lists (ACLs). An ACL is a user-ordered set of rules used to configure the forwarding behavior in a device. Each rule is used to find a match on a packet and define actions that will be performed on the packet.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="8519"/>
          <seriesInfo name="DOI" value="10.17487/RFC8519"/>
        </reference>
        <reference anchor="RFC8520" target="https://www.rfc-editor.org/info/rfc8520" quoteTitle="true" derivedAnchor="RFC8520">
          <front>
            <title>Manufacturer Usage Description Specification</title>
            <author fullname="E. Lear" initials="E." surname="Lear"/>
            <author fullname="R. Droms" initials="R." surname="Droms"/>
            <author fullname="D. Romascanu" initials="D." surname="Romascanu"/>
            <date month="March" year="2019"/>
            <abstract>
              <t indent="0">This memo specifies a component-based architecture for Manufacturer Usage Descriptions (MUDs). The goal of MUD is to provide a means for end devices to signal to the network what sort of access and network functionality they require to properly function. The initial focus is on access control. Later work can delve into other aspects.</t>
              <t indent="0">This memo specifies two YANG modules, IPv4 and IPv6 DHCP options, a Link Layer Discovery Protocol (LLDP) TLV, a URL, an X.509 certificate extension, and a means to sign and verify the descriptions.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="8520"/>
          <seriesInfo name="DOI" value="10.17487/RFC8520"/>
        </reference>
        <reference anchor="RFC8701" target="https://www.rfc-editor.org/info/rfc8701" quoteTitle="true" derivedAnchor="RFC8701">
          <front>
            <title>Applying Generate Random Extensions And Sustain Extensibility (GREASE) to TLS Extensibility</title>
            <author fullname="D. Benjamin" initials="D." surname="Benjamin"/>
            <date month="January" year="2020"/>
            <abstract>
              <t indent="0">This document describes GREASE (Generate Random Extensions And Sustain Extensibility), a mechanism to prevent extensibility failures in the TLS ecosystem. It reserves a set of TLS protocol values that may be advertised to ensure peers correctly handle unknown values.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="8701"/>
          <seriesInfo name="DOI" value="10.17487/RFC8701"/>
        </reference>
        <reference anchor="RFC8879" target="https://www.rfc-editor.org/info/rfc8879" quoteTitle="true" derivedAnchor="RFC8879">
          <front>
            <title>TLS Certificate Compression</title>
            <author fullname="A. Ghedini" initials="A." surname="Ghedini"/>
            <author fullname="V. Vasiliev" initials="V." surname="Vasiliev"/>
            <date month="December" year="2020"/>
            <abstract>
              <t indent="0">In TLS handshakes, certificate chains often take up the majority of the bytes transmitted.</t>
              <t indent="0">This document describes how certificate chains can be compressed to reduce the amount of data transmitted and avoid some round trips.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="8879"/>
          <seriesInfo name="DOI" value="10.17487/RFC8879"/>
        </reference>
        <reference anchor="RFC9000" target="https://www.rfc-editor.org/info/rfc9000" quoteTitle="true" derivedAnchor="RFC9000">
          <front>
            <title>QUIC: A UDP-Based Multiplexed and Secure Transport</title>
            <author fullname="J. Iyengar" initials="J." role="editor" surname="Iyengar"/>
            <author fullname="M. Thomson" initials="M." role="editor" surname="Thomson"/>
            <date month="May" year="2021"/>
            <abstract>
              <t indent="0">This document defines the core of the QUIC transport protocol. QUIC provides applications with flow-controlled streams for structured communication, low-latency connection establishment, and network path migration. QUIC includes security measures that ensure confidentiality, integrity, and availability in a range of deployment circumstances. Accompanying documents describe the integration of TLS for key negotiation, loss detection, and an exemplary congestion control algorithm.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="9000"/>
          <seriesInfo name="DOI" value="10.17487/RFC9000"/>
        </reference>
        <reference anchor="RFC9147" target="https://www.rfc-editor.org/info/rfc9147" quoteTitle="true" derivedAnchor="RFC9147">
          <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 indent="0">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 indent="0">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 indent="0">This document obsoletes RFC 6347.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="9147"/>
          <seriesInfo name="DOI" value="10.17487/RFC9147"/>
        </reference>
        <reference anchor="RFC9640" target="https://www.rfc-editor.org/info/rfc9640" quoteTitle="true" derivedAnchor="RFC9640">
          <front>
            <title>YANG Data Types and Groupings for Cryptography</title>
            <author fullname="K. Watsen" initials="K." surname="Watsen"/>
            <date month="October" year="2024"/>
            <abstract>
              <t indent="0">This document presents a YANG 1.1 (RFC 7950) module defining identities, typedefs, and groupings useful to cryptographic applications.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="9640"/>
          <seriesInfo name="DOI" value="10.17487/RFC9640"/>
        </reference>
        <reference anchor="X690" target="https://www.itu.int/rec/T-REC-X.690-202102-I/en" quoteTitle="true" derivedAnchor="X690">
          <front>
            <title>Information technology - ASN.1 encoding Rules: Specification of Basic Encoding Rules (BER), Canonical Encoding Rules (CER) and Distinguished Encoding Rules (DER)</title>
            <author>
              <organization showOnFrontPage="true">ITU-T</organization>
            </author>
            <date year="2021"/>
          </front>
          <seriesInfo name="ITU-T Recommendation" value="X.690"/>
        </reference>
      </references>
      <references pn="section-12.2">
        <name slugifiedName="name-informative-references">Informative References</name>
        <reference anchor="CLEAR-AS-MUD" target="https://arxiv.org/pdf/1804.04358.pdf" quoteTitle="true" derivedAnchor="CLEAR-AS-MUD">
          <front>
            <title>Clear as MUD: Generating, Validating and Applying IoT Behaviorial Profiles (Technical Report)</title>
            <author fullname="Ayyoob Hamza"/>
            <author fullname="Dinesha Ranathunga"/>
            <author fullname="H. Habibi Gharakheili"/>
            <author fullname="Matthew Roughan"/>
            <author fullname="Vijay Sivaraman"/>
            <date month="April" year="2018"/>
          </front>
          <refcontent>arXiv:1804.04358</refcontent>
          <seriesInfo name="DOI" value="10.48550/arXiv.1804.04358"/>
        </reference>
        <reference anchor="CRYPTO-VULNERABILITY" target="https://securityboulevard.com/2020/01/exploiting-the-windows-cryptoapi-vulnerability/" quoteTitle="true" derivedAnchor="CRYPTO-VULNERABILITY">
          <front>
            <title>Exploiting the Windows CryptoAPI Vulnerability</title>
            <author fullname="Ben Perez" initials="B." surname="Perez">
              <organization showOnFrontPage="true">Cisco</organization>
            </author>
            <date month="January" year="2020"/>
          </front>
        </reference>
        <reference anchor="EVE" target="https://secure.cisco.com/secure-firewall/docs/encrypted-visibility-engine" quoteTitle="true" derivedAnchor="EVE">
          <front>
            <title>Encrypted Visibility Engine</title>
            <author fullname="" initials="" surname="">
              <organization showOnFrontPage="true">Cisco</organization>
            </author>
            <date month="" year=""/>
          </front>
          <refcontent>Cisco Secure Firewall documentation</refcontent>
        </reference>
        <reference anchor="I-D.ietf-uta-tls13-iot-profile" target="https://datatracker.ietf.org/doc/html/draft-ietf-uta-tls13-iot-profile-13" quoteTitle="true" derivedAnchor="IoT-PROFILE">
          <front>
            <title>TLS/DTLS 1.3 Profiles for the Internet of Things</title>
            <author initials="H." surname="Tschofenig" fullname="Hannes Tschofenig">
              <organization showOnFrontPage="true">University of Applied Sciences Bonn-Rhein-Sieg</organization>
            </author>
            <author initials="T." surname="Fossati" fullname="Thomas Fossati">
              <organization showOnFrontPage="true">Linaro</organization>
            </author>
            <author initials="M." surname="Richardson" fullname="Michael Richardson">
              <organization showOnFrontPage="true">Sandelman Software Works</organization>
            </author>
            <date month="March" day="3" year="2025"/>
            <abstract>
              <t indent="0">   RFC 7925 offers guidance to developers on using TLS/DTLS 1.2 for
   Internet of Things (IoT) devices with resource constraints.  This
   document is a companion to RFC 7925, defining TLS/DTLS 1.3 profiles
   for IoT devices.  Additionally, it updates RFC 7925 with respect to
   the X.509 certificate profile and ciphersuite requirements.

Discussion Venues

   This note is to be removed before publishing as an RFC.

   Source for this draft and an issue tracker can be found at
   https://github.com/thomas-fossati/draft-tls13-iot.

              </t>
            </abstract>
          </front>
          <seriesInfo name="Internet-Draft" value="draft-ietf-uta-tls13-iot-profile-13"/>
          <refcontent>Work in Progress</refcontent>
        </reference>
        <reference anchor="MALWARE-DOH" target="https://www.zdnet.com/article/first-ever-malware-strain-spotted-abusing-new-doh-dns-over-https-protocol/" quoteTitle="true" derivedAnchor="MALWARE-DOH">
          <front>
            <title>First-ever malware strain spotted abusing new DoH (DNS over HTTPS) protocol</title>
            <author fullname="Catalin Cimpanu" initials="C." surname="Cimpanu">
            </author>
            <date month="July" year="2019"/>
          </front>
          <refcontent>ZDNET</refcontent>
        </reference>
        <reference anchor="MALWARE-TLS" target="https://dl.acm.org/citation.cfm?id=3355601" quoteTitle="true" derivedAnchor="MALWARE-TLS">
          <front>
            <title>TLS Beyond the Browser: Combining End Host and Network Data to Understand Application Behavior</title>
            <author fullname="Blake Anderson" initials="B." surname="Anderson">
              <organization showOnFrontPage="true">Cisco</organization>
            </author>
            <author fullname="David McGrew" initials="D." surname="McGrew">
              <organization showOnFrontPage="true">Cisco</organization>
            </author>
            <date month="October" year="2019"/>
          </front>
          <refcontent>IMC '19: Proceedings of the Internet Measurement Conference, pp. 379-392</refcontent>
          <seriesInfo name="DOI" value="10.1145/3355369.3355601"/>
        </reference>
        <reference anchor="RFC6020" target="https://www.rfc-editor.org/info/rfc6020" quoteTitle="true" derivedAnchor="RFC6020">
          <front>
            <title>YANG - A Data Modeling Language for the Network Configuration Protocol (NETCONF)</title>
            <author fullname="M. Bjorklund" initials="M." role="editor" surname="Bjorklund"/>
            <date month="October" year="2010"/>
            <abstract>
              <t indent="0">YANG is a data modeling language used to model configuration and state data manipulated by the Network Configuration Protocol (NETCONF), NETCONF remote procedure calls, and NETCONF notifications. [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="6020"/>
          <seriesInfo name="DOI" value="10.17487/RFC6020"/>
        </reference>
        <reference anchor="RFC6066" target="https://www.rfc-editor.org/info/rfc6066" quoteTitle="true" derivedAnchor="RFC6066">
          <front>
            <title>Transport Layer Security (TLS) Extensions: Extension Definitions</title>
            <author fullname="D. Eastlake 3rd" initials="D." surname="Eastlake 3rd"/>
            <date month="January" year="2011"/>
            <abstract>
              <t indent="0">This document provides specifications for existing TLS extensions. It is a companion document for RFC 5246, "The Transport Layer Security (TLS) Protocol Version 1.2". The extensions specified are server_name, max_fragment_length, client_certificate_url, trusted_ca_keys, truncated_hmac, and status_request. [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="6066"/>
          <seriesInfo name="DOI" value="10.17487/RFC6066"/>
        </reference>
        <reference anchor="RFC7301" target="https://www.rfc-editor.org/info/rfc7301" quoteTitle="true" derivedAnchor="RFC7301">
          <front>
            <title>Transport Layer Security (TLS) Application-Layer Protocol Negotiation Extension</title>
            <author fullname="S. Friedl" initials="S." surname="Friedl"/>
            <author fullname="A. Popov" initials="A." surname="Popov"/>
            <author fullname="A. Langley" initials="A." surname="Langley"/>
            <author fullname="E. Stephan" initials="E." surname="Stephan"/>
            <date month="July" year="2014"/>
            <abstract>
              <t indent="0">This document describes a Transport Layer Security (TLS) extension for application-layer protocol negotiation within the TLS handshake. For instances in which multiple application protocols are supported on the same TCP or UDP port, this extension allows the application layer to negotiate which protocol will be used within the TLS connection.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="7301"/>
          <seriesInfo name="DOI" value="10.17487/RFC7301"/>
        </reference>
        <reference anchor="RFC7366" target="https://www.rfc-editor.org/info/rfc7366" quoteTitle="true" derivedAnchor="RFC7366">
          <front>
            <title>Encrypt-then-MAC for Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS)</title>
            <author fullname="P. Gutmann" initials="P." surname="Gutmann"/>
            <date month="September" year="2014"/>
            <abstract>
              <t indent="0">This document describes a means of negotiating the use of the encrypt-then-MAC security mechanism in place of the existing MAC-then-encrypt mechanism in Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS). The MAC-then-encrypt mechanism has been the subject of a number of security vulnerabilities over a period of many years.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="7366"/>
          <seriesInfo name="DOI" value="10.17487/RFC7366"/>
        </reference>
        <reference anchor="RFC7858" target="https://www.rfc-editor.org/info/rfc7858" quoteTitle="true" derivedAnchor="RFC7858">
          <front>
            <title>Specification for DNS over Transport Layer Security (TLS)</title>
            <author fullname="Z. Hu" initials="Z." surname="Hu"/>
            <author fullname="L. Zhu" initials="L." surname="Zhu"/>
            <author fullname="J. Heidemann" initials="J." surname="Heidemann"/>
            <author fullname="A. Mankin" initials="A." surname="Mankin"/>
            <author fullname="D. Wessels" initials="D." surname="Wessels"/>
            <author fullname="P. Hoffman" initials="P." surname="Hoffman"/>
            <date month="May" year="2016"/>
            <abstract>
              <t indent="0">This document describes the use of Transport Layer Security (TLS) to provide privacy for DNS. Encryption provided by TLS eliminates opportunities for eavesdropping and on-path tampering with DNS queries in the network, such as discussed in RFC 7626. In addition, this document specifies two usage profiles for DNS over TLS and provides advice on performance considerations to minimize overhead from using TCP and TLS with DNS.</t>
              <t indent="0">This document focuses on securing stub-to-recursive traffic, as per the charter of the DPRIVE Working Group. It does not prevent future applications of the protocol to recursive-to-authoritative traffic.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="7858"/>
          <seriesInfo name="DOI" value="10.17487/RFC7858"/>
        </reference>
        <reference anchor="RFC7925" target="https://www.rfc-editor.org/info/rfc7925" quoteTitle="true" derivedAnchor="RFC7925">
          <front>
            <title>Transport Layer Security (TLS) / Datagram Transport Layer Security (DTLS) Profiles for the Internet of Things</title>
            <author fullname="H. Tschofenig" initials="H." role="editor" surname="Tschofenig"/>
            <author fullname="T. Fossati" initials="T." surname="Fossati"/>
            <date month="July" year="2016"/>
            <abstract>
              <t indent="0">A common design pattern in Internet of Things (IoT) deployments is the use of a constrained device that collects data via sensors or controls actuators for use in home automation, industrial control systems, smart cities, and other IoT deployments.</t>
              <t indent="0">This document defines a Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS) 1.2 profile that offers communications security for this data exchange thereby preventing eavesdropping, tampering, and message forgery. The lack of communication security is a common vulnerability in IoT products that can easily be solved by using these well-researched and widely deployed Internet security protocols.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="7925"/>
          <seriesInfo name="DOI" value="10.17487/RFC7925"/>
        </reference>
        <reference anchor="RFC7951" target="https://www.rfc-editor.org/info/rfc7951" quoteTitle="true" derivedAnchor="RFC7951">
          <front>
            <title>JSON Encoding of Data Modeled with YANG</title>
            <author fullname="L. Lhotka" initials="L." surname="Lhotka"/>
            <date month="August" year="2016"/>
            <abstract>
              <t indent="0">This document defines encoding rules for representing configuration data, state data, parameters of Remote Procedure Call (RPC) operations or actions, and notifications defined using YANG as JavaScript Object Notation (JSON) text.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="7951"/>
          <seriesInfo name="DOI" value="10.17487/RFC7951"/>
        </reference>
        <reference anchor="RFC8126" target="https://www.rfc-editor.org/info/rfc8126" quoteTitle="true" derivedAnchor="RFC8126">
          <front>
            <title>Guidelines for Writing an IANA Considerations Section in RFCs</title>
            <author fullname="M. Cotton" initials="M." surname="Cotton"/>
            <author fullname="B. Leiba" initials="B." surname="Leiba"/>
            <author fullname="T. Narten" initials="T." surname="Narten"/>
            <date month="June" year="2017"/>
            <abstract>
              <t indent="0">Many protocols make use of points of extensibility that use constants to identify various protocol parameters. To ensure that the values in these fields do not have conflicting uses and to promote interoperability, their allocations are often coordinated by a central record keeper. For IETF protocols, that role is filled by the Internet Assigned Numbers Authority (IANA).</t>
              <t indent="0">To make assignments in a given registry prudently, guidance describing the conditions under which new values should be assigned, as well as when and how modifications to existing values can be made, is needed. This document defines a framework for the documentation of these guidelines by specification authors, in order to assure that the provided guidance for the IANA Considerations is clear and addresses the various issues that are likely in the operation of a registry.</t>
              <t indent="0">This is the third edition of this document; it obsoletes RFC 5226.</t>
            </abstract>
          </front>
          <seriesInfo name="BCP" value="26"/>
          <seriesInfo name="RFC" value="8126"/>
          <seriesInfo name="DOI" value="10.17487/RFC8126"/>
        </reference>
        <reference anchor="RFC8340" target="https://www.rfc-editor.org/info/rfc8340" quoteTitle="true" derivedAnchor="RFC8340">
          <front>
            <title>YANG Tree Diagrams</title>
            <author fullname="M. Bjorklund" initials="M." surname="Bjorklund"/>
            <author fullname="L. Berger" initials="L." role="editor" surname="Berger"/>
            <date month="March" year="2018"/>
            <abstract>
              <t indent="0">This document captures the current syntax used in YANG module tree diagrams. The purpose of this document is to provide a single location for this definition. This syntax may be updated from time to time based on the evolution of the YANG language.</t>
            </abstract>
          </front>
          <seriesInfo name="BCP" value="215"/>
          <seriesInfo name="RFC" value="8340"/>
          <seriesInfo name="DOI" value="10.17487/RFC8340"/>
        </reference>
        <reference anchor="RFC8447" target="https://www.rfc-editor.org/info/rfc8447" quoteTitle="true" derivedAnchor="RFC8447">
          <front>
            <title>IANA Registry Updates for TLS and DTLS</title>
            <author fullname="J. Salowey" initials="J." surname="Salowey"/>
            <author fullname="S. Turner" initials="S." surname="Turner"/>
            <date month="August" year="2018"/>
            <abstract>
              <t indent="0">This document describes a number of changes to TLS and DTLS IANA registries that range from adding notes to the registry all the way to changing the registration policy. These changes were mostly motivated by WG review of the TLS- and DTLS-related registries undertaken as part of the TLS 1.3 development process.</t>
              <t indent="0">This document updates the following RFCs: 3749, 5077, 4680, 5246, 5705, 5878, 6520, and 7301.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="8447"/>
          <seriesInfo name="DOI" value="10.17487/RFC8447"/>
        </reference>
        <reference anchor="RFC8472" target="https://www.rfc-editor.org/info/rfc8472" quoteTitle="true" derivedAnchor="RFC8472">
          <front>
            <title>Transport Layer Security (TLS) Extension for Token Binding Protocol Negotiation</title>
            <author fullname="A. Popov" initials="A." role="editor" surname="Popov"/>
            <author fullname="M. Nystroem" initials="M." surname="Nystroem"/>
            <author fullname="D. Balfanz" initials="D." surname="Balfanz"/>
            <date month="October" year="2018"/>
            <abstract>
              <t indent="0">This document specifies a Transport Layer Security (TLS) extension for the negotiation of Token Binding protocol version and key parameters. Negotiation of Token Binding in TLS 1.3 and later versions is beyond the scope of this document.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="8472"/>
          <seriesInfo name="DOI" value="10.17487/RFC8472"/>
        </reference>
        <reference anchor="RFC8484" target="https://www.rfc-editor.org/info/rfc8484" quoteTitle="true" derivedAnchor="RFC8484">
          <front>
            <title>DNS Queries over HTTPS (DoH)</title>
            <author fullname="P. Hoffman" initials="P." surname="Hoffman"/>
            <author fullname="P. McManus" initials="P." surname="McManus"/>
            <date month="October" year="2018"/>
            <abstract>
              <t indent="0">This document defines a protocol for sending DNS queries and getting DNS responses over HTTPS. Each DNS query-response pair is mapped into an HTTP exchange.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="8484"/>
          <seriesInfo name="DOI" value="10.17487/RFC8484"/>
        </reference>
        <reference anchor="RFC8576" target="https://www.rfc-editor.org/info/rfc8576" quoteTitle="true" derivedAnchor="RFC8576">
          <front>
            <title>Internet of Things (IoT) Security: State of the Art and Challenges</title>
            <author fullname="O. Garcia-Morchon" initials="O." surname="Garcia-Morchon"/>
            <author fullname="S. Kumar" initials="S." surname="Kumar"/>
            <author fullname="M. Sethi" initials="M." surname="Sethi"/>
            <date month="April" year="2019"/>
            <abstract>
              <t indent="0">The Internet of Things (IoT) concept refers to the usage of standard Internet protocols to allow for human-to-thing and thing-to-thing communication. The security needs for IoT systems are well recognized, and many standardization steps to provide security have been taken -- for example, the specification of the Constrained Application Protocol (CoAP) secured with Datagram Transport Layer Security (DTLS). However, security challenges still exist, not only because there are some use cases that lack a suitable solution, but also because many IoT devices and systems have been designed and deployed with very limited security capabilities. In this document, we first discuss the various stages in the lifecycle of a thing. Next, we document the security threats to a thing and the challenges that one might face to protect against these threats. Lastly, we discuss the next steps needed to facilitate the deployment of secure IoT systems. This document can be used by implementers and authors of IoT specifications as a reference for details about security considerations while documenting their specific security challenges, threat models, and mitigations.</t>
              <t indent="0">This document is a product of the IRTF Thing-to-Thing Research Group (T2TRG).</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="8576"/>
          <seriesInfo name="DOI" value="10.17487/RFC8576"/>
        </reference>
        <reference anchor="RFC8613" target="https://www.rfc-editor.org/info/rfc8613" quoteTitle="true" derivedAnchor="RFC8613">
          <front>
            <title>Object Security for Constrained RESTful Environments (OSCORE)</title>
            <author fullname="G. Selander" initials="G." surname="Selander"/>
            <author fullname="J. Mattsson" initials="J." surname="Mattsson"/>
            <author fullname="F. Palombini" initials="F." surname="Palombini"/>
            <author fullname="L. Seitz" initials="L." surname="Seitz"/>
            <date month="July" year="2019"/>
            <abstract>
              <t indent="0">This document defines Object Security for Constrained RESTful Environments (OSCORE), a method for application-layer protection of the Constrained Application Protocol (CoAP), using CBOR Object Signing and Encryption (COSE). OSCORE provides end-to-end protection between endpoints communicating using CoAP or CoAP-mappable HTTP. OSCORE is designed for constrained nodes and networks supporting a range of proxy operations, including translation between different transport protocols.</t>
              <t indent="0">Although an optional functionality of CoAP, OSCORE alters CoAP options processing and IANA registration. Therefore, this document updates RFC 7252.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="8613"/>
          <seriesInfo name="DOI" value="10.17487/RFC8613"/>
        </reference>
        <reference anchor="RFC9052" target="https://www.rfc-editor.org/info/rfc9052" quoteTitle="true" derivedAnchor="RFC9052">
          <front>
            <title>CBOR Object Signing and Encryption (COSE): Structures and Process</title>
            <author fullname="J. Schaad" initials="J." surname="Schaad"/>
            <date month="August" year="2022"/>
            <abstract>
              <t indent="0">Concise Binary Object Representation (CBOR) is a data format designed for small code size and small message size. There is a need to be able to define basic security services for this data format. This document defines the CBOR Object Signing and Encryption (COSE) protocol. This specification describes how to create and process signatures, message authentication codes, and encryption using CBOR for serialization. This specification additionally describes how to represent cryptographic keys using CBOR.</t>
              <t indent="0">This document, along with RFC 9053, obsoletes RFC 8152.</t>
            </abstract>
          </front>
          <seriesInfo name="STD" value="96"/>
          <seriesInfo name="RFC" value="9052"/>
          <seriesInfo name="DOI" value="10.17487/RFC9052"/>
        </reference>
        <reference anchor="RFC9325" target="https://www.rfc-editor.org/info/rfc9325" quoteTitle="true" derivedAnchor="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 indent="0">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 indent="0">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>
        <reference anchor="RFC9462" target="https://www.rfc-editor.org/info/rfc9462" quoteTitle="true" derivedAnchor="RFC9462">
          <front>
            <title>Discovery of Designated Resolvers</title>
            <author fullname="T. Pauly" initials="T." surname="Pauly"/>
            <author fullname="E. Kinnear" initials="E." surname="Kinnear"/>
            <author fullname="C. A. Wood" initials="C. A." surname="Wood"/>
            <author fullname="P. McManus" initials="P." surname="McManus"/>
            <author fullname="T. Jensen" initials="T." surname="Jensen"/>
            <date month="November" year="2023"/>
            <abstract>
              <t indent="0">This document defines Discovery of Designated Resolvers (DDR), a set of mechanisms for DNS clients to use DNS records to discover a resolver's encrypted DNS configuration. An Encrypted DNS Resolver discovered in this manner is referred to as a "Designated Resolver". These mechanisms can be used to move from unencrypted DNS to encrypted DNS when only the IP address of a resolver is known. These mechanisms are designed to be limited to cases where Unencrypted DNS Resolvers and their Designated Resolvers are operated by the same entity or cooperating entities. It can also be used to discover support for encrypted DNS protocols when the name of an Encrypted DNS Resolver is known.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="9462"/>
          <seriesInfo name="DOI" value="10.17487/RFC9462"/>
        </reference>
        <reference anchor="RFC9463" target="https://www.rfc-editor.org/info/rfc9463" quoteTitle="true" derivedAnchor="RFC9463">
          <front>
            <title>DHCP and Router Advertisement Options for the Discovery of Network-designated Resolvers (DNR)</title>
            <author fullname="M. Boucadair" initials="M." role="editor" surname="Boucadair"/>
            <author fullname="T. Reddy.K" initials="T." role="editor" surname="Reddy.K"/>
            <author fullname="D. Wing" initials="D." surname="Wing"/>
            <author fullname="N. Cook" initials="N." surname="Cook"/>
            <author fullname="T. Jensen" initials="T." surname="Jensen"/>
            <date month="November" year="2023"/>
            <abstract>
              <t indent="0">This document specifies new DHCP and IPv6 Router Advertisement options to discover encrypted DNS resolvers (e.g., DNS over HTTPS, DNS over TLS, and DNS over QUIC). Particularly, it allows a host to learn an Authentication Domain Name together with a list of IP addresses and a set of service parameters to reach such encrypted DNS resolvers.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="9463"/>
          <seriesInfo name="DOI" value="10.17487/RFC9463"/>
        </reference>
        <reference anchor="SLOWLORIS" target="https://en.wikipedia.org/w/index.php?title=Slowloris_(cyber_attack)&amp;oldid=1263305193" quoteTitle="true" derivedAnchor="SLOWLORIS">
          <front>
            <title>Slowloris (cyber attack)</title>
            <author>
              <organization showOnFrontPage="true">Wikipedia</organization>
            </author>
            <date month="December" year="2024"/>
          </front>
        </reference>
        <reference anchor="I-D.ietf-tls-esni" target="https://datatracker.ietf.org/doc/html/draft-ietf-tls-esni-24" quoteTitle="true" derivedAnchor="TLS-ESNI">
          <front>
            <title>TLS Encrypted Client Hello</title>
            <author initials="E." surname="Rescorla" fullname="Eric Rescorla">
              <organization showOnFrontPage="true">Independent</organization>
            </author>
            <author initials="K." surname="Oku" fullname="Kazuho Oku">
              <organization showOnFrontPage="true">Fastly</organization>
            </author>
            <author initials="N." surname="Sullivan" fullname="Nick Sullivan">
              <organization showOnFrontPage="true">Cryptography Consulting LLC</organization>
            </author>
            <author initials="C. A." surname="Wood" fullname="Christopher A. Wood">
              <organization showOnFrontPage="true">Cloudflare</organization>
            </author>
            <date month="March" day="20" year="2025"/>
            <abstract>
              <t indent="0">   This document describes a mechanism in Transport Layer Security (TLS)
   for encrypting a ClientHello message under a server public key.

Discussion Venues

   This note is to be removed before publishing as an RFC.

   Source for this draft and an issue tracker can be found at
   https://github.com/tlswg/draft-ietf-tls-esni
   (https://github.com/tlswg/draft-ietf-tls-esni).

              </t>
            </abstract>
          </front>
          <seriesInfo name="Internet-Draft" value="draft-ietf-tls-esni-24"/>
          <refcontent>Work in Progress</refcontent>
        </reference>
        <reference anchor="X501" target="https://www.itu.int/rec/T-REC-X.501-201910-I/en" quoteTitle="true" derivedAnchor="X501">
          <front>
            <title>Information Technology - Open Systems Interconnection - The Directory: Models</title>
            <author>
              <organization showOnFrontPage="true"/>
            </author>
            <date month="October" year="2019"/>
          </front>
          <seriesInfo name="ITU-T Recommendation" value="X.501"/>
        </reference>
        <reference anchor="I-D.ietf-netmod-rfc8407bis" target="https://datatracker.ietf.org/doc/html/draft-ietf-netmod-rfc8407bis-23" quoteTitle="true" derivedAnchor="YANG-GUIDELINES">
          <front>
            <title>Guidelines for Authors and Reviewers of Documents Containing YANG Data Models</title>
            <author initials="A." surname="Bierman" fullname="Andy Bierman">
              <organization showOnFrontPage="true">YumaWorks</organization>
            </author>
            <author initials="M." surname="Boucadair" fullname="Mohamed Boucadair">
              <organization showOnFrontPage="true">Orange</organization>
            </author>
            <author initials="Q." surname="Wu" fullname="Qin Wu">
              <organization showOnFrontPage="true">Huawei</organization>
            </author>
            <date month="April" day="15" year="2025"/>
            <abstract>
              <t indent="0">   This memo provides guidelines for authors and reviewers of
   specifications containing YANG modules, including IANA-maintained
   modules.  Recommendations and procedures are defined, which are
   intended to increase interoperability and usability of Network
   Configuration Protocol (NETCONF) and RESTCONF protocol
   implementations that utilize YANG modules.  This document obsoletes
   RFC 8407.

   Also, this document updates RFC 8126 by providing additional
   guidelines for writing the IANA considerations for RFCs that specify
   IANA-maintained modules.  The document also updates RFC 6020 by
   clarifying how modules and their revisions are handled by IANA.

              </t>
            </abstract>
          </front>
          <seriesInfo name="Internet-Draft" value="draft-ietf-netmod-rfc8407bis-23"/>
          <refcontent>Work in Progress</refcontent>
        </reference>
      </references>
    </references>
    <section anchor="acknowledgments" numbered="false" toc="include" removeInRFC="false" pn="section-appendix.a">
      <name slugifiedName="name-acknowledgments">Acknowledgments</name>
      <t indent="0" pn="section-appendix.a-1">Thanks to <contact fullname="Flemming     Andreasen"/>, <contact fullname="Shashank Jain"/>, <contact fullname="Michael Richardson"/>, <contact fullname="Piyush Joshi"/>,
    <contact fullname="Eliot Lear"/>, <contact fullname="Harsha Joshi"/>,
    <contact fullname="Qin Wu"/>, <contact fullname="Mohamed Boucadair"/>,
    <contact fullname="Ben Schwartz"/>, <contact fullname="Eric Rescorla"/>,
    <contact fullname="Panwei William"/>, <contact fullname="Nick Lamb"/>,
    <contact fullname="Tom Petch"/>, <contact fullname="Paul Wouters"/>,
    <contact fullname="Thomas Fossati"/>, and <contact fullname="Nick     Harper"/> for the discussion and comments.</t>
      <t indent="0" pn="section-appendix.a-2">Thanks to <contact fullname="Xufeng Liu"/> for YANGDOCTOR review. Thanks to <contact fullname="Linda Dunbar"/> for SECDIR review. Thanks to <contact fullname="Qin Wu"/> for OPSDIR review. Thanks to <contact fullname="R. Gieben"/> for DNSDIR review.</t>
      <t indent="0" pn="section-appendix.a-3">Thanks to <contact fullname="Roman     Danyliw"/>, <contact fullname="Orie Steele"/>, <contact fullname="Éric     Vyncke"/>, <contact fullname="Mahesh Jethanandani"/>, <contact fullname="Murray Kucherawy"/>, <contact fullname="Zaheduzzaman Sarker"/>,
    and <contact fullname="Deb Cooley"/> for the IESG review.</t>
    </section>
    <section anchor="authors-addresses" numbered="false" removeInRFC="false" toc="include" pn="section-appendix.b">
      <name slugifiedName="name-authors-addresses">Authors' Addresses</name>
      <author fullname="Tirumaleswar Reddy.K" initials="T." surname="Reddy.K">
        <organization showOnFrontPage="true">Nokia</organization>
        <address>
          <postal>
            <country>India</country>
          </postal>
          <email>kondtir@gmail.com</email>
        </address>
      </author>
      <author fullname="Dan Wing" initials="D." surname="Wing">
        <organization abbrev="Citrix" showOnFrontPage="true">Citrix Systems, Inc.</organization>
        <address>
          <postal>
            <street>4988 Great America Pkwy</street>
            <city>Santa Clara</city>
            <region>CA</region>
            <code>95054</code>
            <country>United States of America</country>
          </postal>
          <email>danwing@gmail.com</email>
        </address>
      </author>
      <author fullname="Blake Anderson" initials="B." surname="Anderson">
        <organization abbrev="Cisco" showOnFrontPage="true">Cisco Systems, Inc.</organization>
        <address>
          <postal>
            <street>170 West Tasman Dr</street>
            <city>San Jose</city>
            <region>CA</region>
            <code>95134</code>
            <country>United States of America</country>
          </postal>
          <email>blake.anderson@cisco.com</email>
        </address>
      </author>
    </section>
  </back>
</rfc>
