rfc9761xml2.original.xml   rfc9761.xml 
<?xml version="1.0" encoding="US-ASCII"?> <?xml version='1.0' encoding='UTF-8'?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?rfc toc="yes"?> <!DOCTYPE rfc [
<?rfc tocompact="yes"?> <!ENTITY nbsp "&#160;">
<?rfc tocdepth="3"?> <!ENTITY zwsp "&#8203;">
<?rfc tocindent="yes"?> <!ENTITY nbhy "&#8209;">
<?rfc symrefs="yes"?> <!ENTITY wj "&#8288;">
<?rfc sortrefs="yes"?> ]>
<?rfc comments="yes"?>
<?rfc inline="yes"?> <rfc xmlns:xi="http://www.w3.org/2001/XInclude" category="std" docName="draft-ie
<?rfc compact="yes"?> tf-opsawg-mud-tls-18" number="9761" ipr="trust200902" obsoletes="" updates="" su
<?rfc subcompact="no"?> bmissionType="IETF" xml:lang="en" tocInclude="true" tocDepth="3" consensus="true
<rfc category="std" docName="draft-ietf-opsawg-mud-tls-18" ipr="trust200902"> " symRefs="true" sortRefs="true" version="3">
<front> <front>
<title abbrev="MUD (D)TLS Profile for IoT devices">Manufacturer Usage
Description (MUD) (D)TLS Profiles for IoT Devices</title>
<author fullname="Tirumaleswar Reddy" initials="T." surname="Reddy"> <!-- [rfced] For clarity, we have updated the title and the first
<organization>Nokia</organization> sentence of the Abstract from the combined abbreviation
"(D)TLS" to "TLS and DTLS". Afterwards, "D(TLS)" will be used in the
document.
Original:
This memo extends the Manufacturer Usage Description (MUD)
specification to allow manufacturers to define (D)TLS profile
parameters.
Current:
This memo extends the Manufacturer Usage Description (MUD)
specification to allow manufacturers to define TLS and DTLS profile
parameters
-->
<title abbrev="MUD (D)TLS Profile for IoT devices">Manufacturer Usage
Description (MUD) for TLS and DTLS Profiles for Internet of Things (IoT) Dev
ices</title>
<seriesInfo name="RFC" value="9761"/>
<author fullname="Tirumaleswar Reddy.K" initials="T." surname="Reddy.K">
<organization>Nokia</organization>
<address> <address>
<postal> <postal>
<street></street>
<country>India</country> <country>India</country>
</postal> </postal>
<email>kondtir@gmail.com</email> <email>kondtir@gmail.com</email>
</address> </address>
</author> </author>
<author fullname="Dan Wing" initials="D." surname="Wing"> <author fullname="Dan Wing" initials="D." surname="Wing">
<organization abbrev="Citrix">Citrix Systems, Inc.</organization> <organization abbrev="Citrix">Citrix Systems, Inc.</organization>
<address> <address>
<postal> <postal>
<street>4988 Great America Pkwy</street> <street>4988 Great America Pkwy</street>
<city>Santa Clara</city> <city>Santa Clara</city>
<region>CA</region> <region>CA</region>
<code>95054</code> <code>95054</code>
<country>United States of America</country>
<country>USA</country>
</postal> </postal>
<email>danwing@gmail.com</email> <email>danwing@gmail.com</email>
</address> </address>
</author> </author>
<author fullname="Blake Anderson" initials="B." surname="Anderson"> <author fullname="Blake Anderson" initials="B." surname="Anderson">
<organization abbrev="Cisco">Cisco Systems, Inc.</organization> <organization abbrev="Cisco">Cisco Systems, Inc.</organization>
<address> <address>
<postal> <postal>
<street>170 West Tasman Dr</street> <street>170 West Tasman Dr</street>
<city>San Jose</city> <city>San Jose</city>
<region>CA</region> <region>CA</region>
<code>95134</code> <code>95134</code>
<country>United States of America</country>
<country>USA</country>
</postal> </postal>
<email>blake.anderson@cisco.com</email> <email>blake.anderson@cisco.com</email>
</address> </address>
</author> </author>
<date month="March" year="2025"/>
<area>OPS</area>
<workgroup>opsawg</workgroup>
<date /> <!-- [rfced] Please insert any keywords (beyond those that appear in
the title) for use on https://www.rfc-editor.org/search. -->
<workgroup>OPSAWG WG</workgroup> <keyword>example</keyword>
<abstract> <abstract>
<t>This memo extends the Manufacturer Usage Description (MUD) <t>This memo extends the Manufacturer Usage Description (MUD)
specification to allow manufacturers to define (D)TLS profile specification to allow manufacturers to define TLS and DTLS profile
parameters. This allows a network security service to identify parameters. This allows a network security service to identify
unexpected (D)TLS usage, which can indicate the presence of unauthorized unexpected (D)TLS usage, which can indicate the presence of unauthorized
software, malware, or security policy-violating traffic on an software, malware, or security policy-violating traffic on an
endpoint.</t> endpoint.</t>
</abstract> </abstract>
</front> </front>
<middle> <middle>
<section anchor="intro" title="Introduction"> <section anchor="intro" numbered="true" toc="default">
<t>Encryption is necessary to enhance the privacy of end users using IoT <name>Introduction</name>
devices. TLS <xref target="RFC8446"></xref> and DTLS <xref <t>Encryption is necessary to enhance the privacy of end users using Inter
target="RFC9147"></xref> are the dominant protocols (counting all (D)TLS net of Things (IoT)
versions) providing encryption for IoT device traffic. Unfortunately, in devices. TLS <xref target="RFC8446" format="default"/> and DTLS <xref targ
et="RFC9147" format="default"/> are the dominant protocols (counting all (D)TLS
versions) that provide encryption for IoT device traffic. Unfortunately, i
n
conjunction with IoT applications' rise of encryption, malware authors conjunction with IoT applications' rise of encryption, malware authors
are also using encryption which thwarts network-based analysis such as are also using encryption that thwarts network-based analysis, such as
deep packet inspection (DPI). Other mechanisms are thus needed to help deep packet inspection (DPI). Thus, other mechanisms are needed to help
detect malware running on an IoT device.</t> detect malware running on an IoT device.</t>
<!-- [rfced] We have rephrased "non-malware" in the text below. Please let us
know if you refer otherwise.
Original:
Malware often reuses certain libraries, and there are notable
differences in how malware uses encryption compared to non-malware.
Current:
Malware often reuses certain libraries, and there are notable
differences in how malware uses encryption compared to software
that is not malware.
-->
<t>Malware often reuses certain libraries, and there are notable <t>Malware often reuses certain libraries, and there are notable
differences in how malware uses encryption compared to non-malware. differences in how malware uses encryption compared to software that is no
Several common patterns in the use of (D)TLS by malware include: <list t malware.
style="symbols"> Several common patterns in the use of (D)TLS by malware include: </t>
<ul spacing="normal">
<li>
<t>Use of older and weaker cryptographic parameters.</t> <t>Use of older and weaker cryptographic parameters.</t>
</li>
<t>TLS server name indication (SNI) extension <xref <li>
target="RFC6066"></xref> and server certificates are composed of <t>TLS server name indication (SNI) extension <xref target="RFC6066" f
ormat="default"/> and server certificates are composed of
subjects with characteristics of a domain generation algorithm (DGA) subjects with characteristics of a domain generation algorithm (DGA)
(e.g., 'www.33mhwt2j.net').</t> (e.g., "www.33mhwt2j.net").</t>
</li>
<li>
<t>Higher use of self-signed certificates compared with typical <t>Higher use of self-signed certificates compared with typical
legitimate software using certificates from a CA trusted by the legitimate software using certificates from a certificate authority (C A) trusted by the
device.</t> device.</t>
</li>
<li>
<t>Discrepancies in the SNI TLS extension and the DNS names in the <t>Discrepancies in the SNI TLS extension and the DNS names in the
SubjectAltName (SAN) X.509 extension in the server certificate SubjectAltName (SAN) X.509 extension in the server certificate
message.</t> message.</t>
</li>
<li>
<t>Discrepancies in the key exchange algorithm and the client public <t>Discrepancies in the key exchange algorithm and the client public
key length in comparison with legitimate flows. As a reminder, the key length in comparison with legitimate flows. As a reminder, the
Client Key Exchange message has been removed from TLS 1.3.</t> Client Key Exchange message has been removed from TLS 1.3.</t>
</li>
<li>
<t>Lower diversity in TLS client advertised extensions compared to <t>Lower diversity in extensions advertised by TLS clients compared to
legitimate clients.</t> legitimate clients.</t>
</li>
<li>
<t>Using privacy enhancing technologies like Tor, Psiphon, Ultrasurf <t>Using privacy enhancing technologies like Tor, Psiphon, Ultrasurf
(see <xref target="malware-tls"></xref>), and evasion techniques (see <xref target="MALWARE-TLS" format="default"/>), and evasion techn iques
such as ClientHello randomization.</t> such as ClientHello randomization.</t>
</li>
<li>
<!-- [rfced] Please clarify the following sentence. We note that DDR is
defined in RFC 9462, and DNR is defined in RFC 9463. We also note that
RFC 9463 is cited for DNR later in this document. May we update the text
as shown below?
Original:
* Using an alternative DNS server (via encrypted transport) to avoid
detection by malware DNS filtering services [malware-doh].
Specifically, malware may not use the Do53 or encrypted DNS server
provided by the local network (DHCP, DNR [RFC9462] or DDR
[RFC9462]).
Perhaps:
* Using an alternative DNS server (via encrypted transport) to avoid
detection by malware DNS filtering services [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)
[RFC9463], or Discovery of Designated Resolvers (DDR) [RFC9462]).
-->
<t>Using an alternative DNS server (via encrypted transport) to <t>Using an alternative DNS server (via encrypted transport) to
avoid detection by malware DNS filtering services <xref avoid detection by malware DNS filtering services <xref target="MALWAR
target="malware-doh"></xref>. Specifically, malware may not use the E-DOH" format="default"/>. Specifically, malware may not use the
Do53 or encrypted DNS server provided by the local network (DHCP, Do53 or encrypted DNS server provided by the local network (DHCP,
DNR <xref target="RFC9462"></xref> or DDR <xref Discovery of Network-designated Resolvers (DNR) <xref target="RFC9462"
target="RFC9462"></xref>).</t> format="default"/>, or Discovery of Designated Resolvers (DDR) <xref target="RF
</list></t> C9462" format="default"/>).</t>
</li>
</ul>
<t>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">
<li>
<t>Permit intended DTLS or TLS use, and block malicious DTLS or
TLS use.
<!-- [rfced] We find that the phrase "layers 3 and 4 Access Control Lists" may
be difficult for readers to interpret. May we rephrase it as below
for readability?
<t>If (D)TLS profile parameters are defined, the following functions are Original:
possible which have a positive impact on the local network security:</t> This is superior to the layers 3 and 4 Access Control Lists
(ACLs) of Manufacturer Usage Description Specification (MUD)
[RFC8520] which are not suitable for broad communication patterns.
<t><list style="symbols"> Perhaps:
<t>Permit intended DTLS or TLS use and block malicious DTLS or TLS This is superior to the Access Control Lists (ACLs) of
use. This is superior to the layers 3 and 4 Access Control Lists Layers 3 and 4 in "Manufacturer Usage Description Specification"
[RFC8520], which are not suitable for broad communication patterns.
-->
This is superior to the layers 3 and 4 Access Control Lists
(ACLs) of Manufacturer Usage Description Specification (MUD) <xref (ACLs) of Manufacturer Usage Description Specification (MUD) <xref
target="RFC8520"></xref> which are not suitable for broad target="RFC8520" format="default"/>, which are not suitable for broad
communication patterns. The goal of this document is to enhance and communication patterns. The goal of this document is to enhance and
complement the existing MUD specifications, rather than to undermine complement the existing MUD specifications rather than undermine
them.</t> them.</t>
</li>
<li>
<t>Ensure TLS certificates are valid. Several TLS deployments have <t>Ensure TLS certificates are valid. Several TLS deployments have
been vulnerable to active Man-In-The-Middle (MITM) attacks because been vulnerable to active Man-In-The-Middle (MITM) attacks because
of the lack of certificate validation or vulnerability in the of the lack of certificate validation or vulnerability in the
certificate validation function (see <xref certificate validation function (see <xref target="CRYPTO-VULNERABILIT
target="cryto-vulnerability"></xref>). By observing (D)TLS profile Y" format="default"/>). By observing (D)TLS profile
parameters, a network element can detect when the TLS SNI mismatches parameters, a network element can detect when the TLS SNI mismatches
the SubjectAltName and when the server's certificate is invalid. In the SubjectAltName and when the server's certificate is invalid. In
(D)TLS 1.2 <xref target="RFC5246"></xref><xref (D)TLS 1.2 <xref target="RFC5246" format="default"/> <xref target="RFC
target="RFC6347"></xref>, the ClientHello, ServerHello and 6347" format="default"/>, the ClientHello, ServerHello, and
Certificate messages are all sent in clear-text. This check is not Certificate messages are all sent in cleartext. This check is not
possible with (D)TLS 1.3, which encrypts the Certificate message possible with (D)TLS 1.3, which encrypts the Certificate message and
thereby hiding the server identity from any intermediary. In (D)TLS therefore hides the server identity from any intermediary. In (D)TLS
1.3, the server certificate validation functions should be executed 1.3, the server certificate validation functions should be executed
within an on-path (D)TLS proxy, if such a proxy exists.</t> within an on-path (D)TLS proxy if such a proxy exists.</t>
</li>
<li>
<t>Support new communication patterns. An IoT device can learn a new <t>Support new communication patterns. An IoT device can learn a new
capability, and the new capability can change the way the IoT device capability, and the new capability can change the way the IoT device
communicates with other devices located in the local network and communicates with other devices located in the local network and the
Internet. There would be an inaccurate policy if an IoT device Internet. There would be an inaccurate policy if an IoT device
rapidly changes the IP addresses and domain names it communicates rapidly changes the IP addresses and domain names it communicates
with while the MUD ACLs were slower to update (see <xref with while the MUD ACLs were slower to update (see <xref target="CLEAR
target="clear-as-mud"></xref>). In such a case, observable (D)TLS -AS-MUD" format="default"/>). In such a case, observable (D)TLS
profile parameters can be used to permit intended use and to block profile parameters can be used to permit intended use and block
malicious behavior from the IoT device.</t> malicious behavior from the IoT device.</t>
</list></t> </li>
</ul>
<t>The YANG module specified in <xref target="YANG2"></xref> of this <t>The YANG module specified in <xref target="YANG2" format="default"/> of
document is an extension of YANG Data Model for Network Access Control this
Lists (ACLs) <xref target="RFC8519"></xref> to enhance MUD <xref document is an extension of "YANG Data Model for Network Access Control
target="RFC8520"></xref> to model observable (D)TLS profile parameters. Lists (ACLs)" <xref target="RFC8519" format="default"/> to enhance MUD <xr
ef target="RFC8520" format="default"/> to model observable (D)TLS profile parame
ters.
Using these (D)TLS profile parameters, an active MUD-enforcing network Using these (D)TLS profile parameters, an active MUD-enforcing network
security service (e.g., firewall) can identify MUD non-compliant (D)TLS security service (e.g., firewall) can identify MUD non-compliant (D)TLS
behavior indicating outdated cryptography or malware. This detection can behavior indicating outdated cryptography or malware. This detection can
prevent malware downloads, block access to malicious domains, enforce prevent malware downloads, block access to malicious domains, enforce
use of strong ciphers, stop data exfiltration, etc. In addition, use of strong ciphers, stop data exfiltration, etc. In addition,
organizations may have policies around acceptable ciphers and organizations may have policies around acceptable ciphers and
certificates for the websites the IoT devices connect to. Examples certificates for the websites the IoT devices connect to. Examples
include no use of old and less secure versions of TLS, no use of include no use of old and less secure versions of TLS, no use of
self-signed certificates, deny-list or accept-list of Certificate self-signed certificates, deny-list or accept-list of Certificate
Authorities, valid certificate expiration time, etc. These policies can Authorities, valid certificate expiration time, etc. These policies can
be enforced by observing the (D)TLS profile parameters. Network security be enforced by observing the (D)TLS profile parameters. Network security
services can use the IoT device's (D)TLS profile parameters to identify services can use the IoT device's (D)TLS profile parameters to identify
legitimate flows by observing (D)TLS sessions, and can make inferences legitimate flows by observing (D)TLS sessions, and can make inferences
to permit legitimate flows and to block malicious or insecure flows. to permit legitimate flows and block malicious or insecure flows.
Additionally, it supports network communications adherence to security Additionally, it supports network communications adherence to security
policies by ensuring that TLS certificates are valid and deprecated policies by ensuring that TLS certificates are valid and deprecated
cipher suites are avoided. The proposed technique is also suitable in cipher suites are avoided. The proposed technique is also suitable in
deployments where decryption techniques are not ideal due to privacy deployments where decryption techniques are not ideal due to privacy
concerns, non-cooperating end-points, and expense.</t> concerns, non-cooperating endpoints, and expense.</t>
</section> </section>
<section anchor="notation" numbered="true" toc="default">
<name>Terminology</name>
<t>
The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQU
IRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL
NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>
RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
"<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to
be interpreted as
described in BCP&nbsp;14 <xref target="RFC2119"/> <xref target="RFC8174"/>
when, and only when, they appear in all capitals, as shown here.
</t>
<section anchor="notation" title="Terminology"> <dl newline="false" spacing="normal">
<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", <dt>(D)TLS:</dt><dd>Used for statements that apply to both
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and Transport Layer Security <xref target="RFC8446" format="default"/>
"OPTIONAL" in this document are to be interpreted as described in BCP 14 and Datagram Transport Layer Security <xref target="RFC6347"
<xref target="RFC2119"></xref><xref target="RFC8174"></xref> when, and format="default"/>. Specific terms "TLS" and "DTLS" are used for any
only when, they appear in all capitals, as shown here.</t> statement that applies to either protocol alone.</dd>
<dt>DoH/DoT:</dt><dd>Refers to DNS-over-HTTPS and/or DNS-over-TLS
<t>"(D)TLS" is used for statements that apply to both Transport Layer <xref target="RFC7858" format="default"/>.</dd>
Security <xref target="RFC8446"></xref> and Datagram Transport Layer <dt>Middlebox:</dt><dd>A middlebox that interacts with TLS traffic
Security <xref target="RFC6347"></xref>. Specific terms "TLS" and "DTLS" can either act as a TLS proxy, intercepting and decrypting the
are used for any statement that applies to either protocol alone.</t> traffic for inspection, or inspect the traffic between TLS peers
without terminating the TLS session.</dd>
<t>'DoH/DoT' refers to DNS-over-HTTPS and/or DNS-over-TLS <xref <dt>Endpoint Security Agent:</dt><dd>An Endpoint Security Agent is a
target="RFC7858"></xref>.</t> software installed on endpoint devices that protects them from
security threats. It provides features such as malware protection,
<t>Middlebox: A middlebox that interacts with TLS traffic can either act firewall, and intrusion prevention to ensure the device's security
as a TLS proxy, intercepting and decrypting the traffic for inspection, and integrity.</dd>
or inspect the traffic between TLS peers without terminating the TLS <dt>Network Security Service:</dt><dd>A Network Security Service
session.</t> refers to a set of mechanisms designed to protect network
communications and resources from attacks.</dd>
<t>Endpoint Security Agent: An Endpoint Security Agent is a software </dl>
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.</t>
<t>Network Security Service: A Network Security Service refers to a set
of mechanisms designed to protect network communications and resources
from attacks.</t>
</section> </section>
<section numbered="true" toc="default">
<section title="Overview of MUD (D)TLS profiles for IoT devices"> <name>Overview of MUD (D)TLS Profiles for IoT devices</name>
<t>In Enterprise networks, protection and detection are typically done <t>In Enterprise networks, protection and detection are typically done
both on end hosts and in the network. Endpoint security agents have deep both on end hosts and in the network. Endpoint security agents have deep
visibility on the devices where they are installed, whereas the network visibility on the devices where they are installed, whereas the network
has broader visibility. Installing endpoint security agents may not be a has broader visibility. Installing endpoint security agents may not be a
viable option on IoT devices, and network security service is an viable option on IoT devices, and network security service is an
efficient means to protect such IoT devices. If the IoT device supports 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 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, can be used by a middlebox to detect and block malware communication,
while at the same time preserving the privacy of legitimate uses of while at the same time preserving the privacy of legitimate uses of
encryption. In addition, it enforces organizational security policies, encryption. In addition, it enforces organizational security policies,
ensuring that devices comply. By monitoring (D)TLS parameters, network ensuring that devices comply. By monitoring (D)TLS parameters, network
administrators can identify and mitigate the use of outdated TLS administrators can identify and mitigate the use of outdated TLS
versions, cryptographic algorithms and non-compliant certificates. The versions, cryptographic algorithms, and non-compliant certificates. The
middlebox need not proxy (D)TLS but can passively observe the parameters 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 of (D)TLS handshakes from IoT devices and gain visibility into TLS 1.2
parameters and partial visibility into TLS 1.3 parameters.</t> parameters and partial visibility into TLS 1.3 parameters.</t>
<t>Malicious agents can try to use the (D)TLS profile parameters of <t>Malicious agents can try to use the (D)TLS profile parameters of
legitimate agents to evade detection, but it becomes a challenge to legitimate agents to evade detection, but it becomes a challenge to
mimic the behavior of various IoT device types and IoT device models mimic the behavior of various IoT device types and IoT device models
from several manufacturers. In other words, malware developers will have from several manufacturers. In other words, malware developers will have
to develop malicious agents per IoT device type, manufacturer and model, to develop malicious agents per IoT device type, manufacturer and model,
infect the device with the tailored malware agent and will have keep up 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. with updates to the device's (D)TLS profile parameters over time.
Furthermore, the malware's command and control server certificates need Furthermore, the malware's command and control server certificates need
to be signed by the same certifying authorities trusted by the IoT to be signed by the same certifying authorities trusted by the IoT
devices. Typically, IoT devices have an infrastructure that supports a devices. Typically, IoT devices have an infrastructure that supports a
rapid deployment of updates, and malware agents will have a rapid deployment of updates, and malware agents will have a
near-impossible task of similarly deploying updates and continuing to near-impossible task of similarly deploying updates and continuing to
mimic the TLS behavior of the IoT device it has infected.</t> mimic the TLS behavior of the IoT device it has infected.</t>
<!-- [rfced] How may this sentence be rephrased for readability?
Specifically: Does "to identify the IoT manufacturer no longer supports
the device" mean
(A) "to indicate that the IoT manufacturer no longer supports the device" or
(B) "to identify which IoT manufacturer no longer supports the device" or
otherwise?
<t>However, if the IoT device has reached end-of-life and the IoT Original:
However, if the IoT device has reached end-of-life 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 Section 3.6 of [RFC8520] can be used by the MUD manager to
identify the IoT manufacturer no longer supports the device.
Perhaps (if option (A)):
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 Section 3.6 of [RFC8520] can be used by the MUD manager to
indicate that the IoT manufacturer no longer supports the device.
-->
<t>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 manufacturer will not issue a firmware or software update to the IoT
device or will not update the MUD file, the "is-supported" attribute device or will not update the MUD file, the "is-supported" attribute
defined in Section 3.6 of <xref target="RFC8520"></xref> can be used by defined in <xref target="RFC8520" sectionFormat="of" section="3.6"/> can b e used by
the MUD manager to identify the IoT manufacturer no longer supports the the MUD manager to identify the IoT manufacturer no longer supports the
device. The end-of-life (EOL) of a device, where the IoT manufacturer no device. The EOL of a device, where the IoT manufacturer no
longer supports it, does not necessarily mean the device is defective. longer supports it, does not necessarily mean the device is defective.
Instead, it signifies that the device is no longer receiving updates, Instead, it signifies that the device is no longer receiving updates,
support, or security patches, which necessitates replacement and support, or security patches, which necessitates replacement and
upgrading to next-generation devices to ensure continued functionality, upgrading to next-generation devices to ensure continued functionality,
security, and compatibility with modern networks. The network security security, and compatibility with modern networks. The network security
service will have to rely on other techniques discussed in <xref service will have to rely on other techniques discussed in <xref target="S
target="Security"></xref> to identify malicious connections until the ecurity" format="default"/> to identify malicious connections until the
device is replaced.</t> device is replaced.</t>
<t>Compromised IoT devices are typically used for launching DDoS attacks <t>Compromised IoT devices are typically used for launching DDoS attacks
(Section 3 of <xref target="RFC8576"></xref>). For example, DDoS attacks (<xref target="RFC8576" sectionFormat="of" section="3"/>). For example, DD
like Slowloris <xref target="slowloris"></xref> and Transport Layer oS attacks
like Slowloris <xref target="SLOWLORIS" format="default"/> and Transport L
ayer
Security (TLS) re-negotiation can be blocked if the victim's server Security (TLS) re-negotiation can be blocked if the victim's server
certificate is not be signed by the same certifying authorities trusted certificate is not be signed by the same certifying authorities trusted
by the IoT device.</t> by the IoT device.</t>
</section> </section>
<section numbered="true" toc="default">
<section title="(D)TLS 1.3 Handshake"> <name>(D)TLS 1.3 Handshake</name>
<t>In (D)TLS 1.3, full (D)TLS handshake inspection is not possible since <t>In (D)TLS 1.3, full (D)TLS handshake inspection is not possible since
all (D)TLS handshake messages excluding the ClientHello message are all (D)TLS handshake messages excluding the ClientHello message are
encrypted. (D)TLS 1.3 has introduced new extensions in the handshake encrypted. (D)TLS 1.3 has introduced new extensions in the handshake
record layers called Encrypted Extensions. Using these extensions record layers called Encrypted Extensions. When using these extensions,
handshake messages will be encrypted and network security services (such handshake messages will be encrypted and network security services (such
as a firewall) are incapable of deciphering the handshake, and thus as a firewall) are incapable of deciphering the handshake, and thus
cannot view the server certificate. However, the ClientHello and cannot view the server certificate. However, the ClientHello and
ServerHello still have some fields visible, such as the list of ServerHello still have some fields visible, such as the list of
supported versions, named groups, cipher suites, signature algorithms supported versions, named groups, cipher suites, signature algorithms,
and extensions in ClientHello, and chosen cipher in the ServerHello. For extensions in ClientHello, and the chosen cipher in the ServerHello. For
instance, if the malware uses evasion techniques like ClientHello instance, if the malware uses evasion techniques like ClientHello
randomization, the observable list of cipher suites and extensions randomization, the observable list of cipher suites and extensions
offered by the malware agent in the ClientHello message will not match offered by the malware agent in the ClientHello message will not match
the list of cipher suites and extensions offered by the legitimate the list of cipher suites and extensions offered by the legitimate
client in the ClientHello message, and the middlebox can block malicious client in the ClientHello message, and the middlebox can block malicious
flows without acting as a (D)TLS 1.3 proxy.</t> flows without acting as a (D)TLS 1.3 proxy.</t>
<section anchor="full" numbered="true" toc="default">
<section anchor="full" title="Full (D)TLS 1.3 Handshake Inspection"> <name>Full (D)TLS 1.3 Handshake Inspection</name>
<t>To obtain more visibility into negotiated TLS 1.3 parameters, a <t>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 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 (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 the Enterprise network and the (D)TLS proxy must meet the security and
privacy requirements of the organization. In other words, the scope of privacy requirements of the organization. In other words, the scope of
middlebox acting as a (D)TLS proxy is restricted to Enterprise network a middlebox acting as a (D)TLS proxy is restricted to the Enterprise net work
owning and managing the IoT devices. The middlebox would have to owning and managing the IoT devices. The middlebox would have to
follow the behaviour detailed in Section 9.3 of <xref follow the behavior detailed in <xref target="RFC8446" sectionFormat="of
target="RFC8446"></xref> to act as a compliant (D)TLS 1.3 proxy.</t> " section="9.3"/> to act as a compliant (D)TLS 1.3 proxy.</t>
<t>To further increase privacy, the Encrypted Client Hello (ECH) extensi
<t>To further increase privacy, Encrypted Client Hello (ECH) extension on
<xref target="I-D.ietf-tls-esni"></xref> prevents passive observation <xref target="I-D.ietf-tls-esni" format="default"/> prevents passive obs
ervation
of the TLS Server Name Indication extension and other potentially of the TLS Server Name Indication extension and other potentially
sensitive fields, such as the ALPN <xref target="RFC7301"></xref>. To sensitive fields, such as the Application-Layer Protocol Negotiation (AL
effectively provide that privacy protection, ECH extension needs to be PN) <xref target="RFC7301" format="default"/>. To
effectively provide that privacy protection, the ECH extension needs to
be
used in conjunction with DNS encryption (e.g., DoH). A middlebox used in conjunction with DNS encryption (e.g., DoH). A middlebox
(e.g., firewall) passively inspecting ECH extension cannot observe the (e.g., firewall) passively inspecting the ECH extension cannot observe t he
encrypted SNI nor observe the encrypted DNS traffic. The middlebox encrypted SNI nor observe the encrypted DNS traffic. The middlebox
acting as a (D)TLS 1.3 proxy that does not support ECH extension will acting as a (D)TLS 1.3 proxy that does not support the ECH extension wil
act as if connecting to the public name and it follows the behaviour l
discussed in Section 6.1.6 of <xref target="I-D.ietf-tls-esni"></xref> 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"/>
to securely signal the client to disable ECH.</t> to securely signal the client to disable ECH.</t>
</section> </section>
<section numbered="true" toc="default">
<section title="Encrypted DNS"> <name>Encrypted DNS</name>
<t>A common usage pattern for certain type of IoT devices (e.g., light <t>A common usage pattern for certain types of IoT devices (e.g.,
bulb) is for it to "call home" to a service that resides on the public light bulb) is for it to "call home" to a service that resides on the
Internet, where that service is referenced through a domain name (A or public Internet, where that service is referenced through a domain
AAAA record). As discussed in Manufacturer Usage Description name (A or AAAA record). As discussed in "Manufacturer Usage
Specification <xref target="RFC8520"></xref>, because these devices Description Specification" <xref target="RFC8520" format="default"/>,
tend to require access to very few sites, all other access should be these devices tend to require access to very few sites. Thus, all
considered suspect. This technique complements MUD policy enforcement other access should be considered suspect. This technique complements
at the TLS level by ensuring that DNS queries are monitored and MUD policy enforcement at the TLS level by ensuring that DNS queries
filtered, thereby enhancing overall security. If an IoT device is are monitored and filtered, thereby enhancing overall security. If an
pre-configured to use a DNS resolver not signaled by the network, the IoT device is pre-configured to use a DNS resolver not signaled by the
MUD policy enforcement point is moved to that resolver, which cannot network, the MUD policy enforcement point is moved to that resolver,
enforce the MUD policy based on domain names (Section 8 of <xref which cannot enforce the MUD policy based on domain names (<xref
target="RFC8520"></xref>). If the DNS query is not accessible for target="RFC8520" sectionFormat="of" section="8"/>). If the DNS query
inspection, it becomes quite difficult for the infrastructure to is not accessible for inspection, it becomes quite difficult for the
detect any issues. Therefore, the use of a DNS resolver that is not infrastructure to detect any issues. Therefore, the use of a DNS
signaled by the network is generally incompatible with MUD. A resolver that is not signaled by the network is generally incompatible
network-designated DoH/DoT server is necessary to allow MUD policy with MUD. A network-designated DoH/DoT server is necessary to allow
enforcement on the local network, for example, using the techniques MUD policy enforcement on the local network, for example, using the
specified in DNR<xref target="RFC9463"> </xref> and DDR <xref techniques specified in DNR <xref target="RFC9463" format="default">
target="RFC9462"></xref>.</t> </xref> and DDR <xref target="RFC9462" format="default"/>.</t>
</section> </section>
</section> </section>
<section anchor="YANG" numbered="true" toc="default">
<section anchor="YANG" title="(D)TLS Profile of a IoT device"> <name>(D)TLS Profile of an IoT device</name>
<t>This document specifies a YANG module for representing (D)TLS <t>This document specifies a YANG module that represents the (D)TLS
profile. This YANG module provides a means to characterize 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 traffic profile of a device. Network security services can use these
profiles to permit conformant traffic or to deny traffic from devices profiles to permit conformant traffic or to deny traffic from devices
that deviates from it. This module uses the cryptographic types defined that deviates from it. This module uses the cryptographic types defined
in <xref target="I-D.ietf-netconf-crypto-types"></xref>. See <xref in <xref target="RFC9640" format="default"/>. See <xref target="RFC7925" f
target="RFC7925"></xref> for (D)TLS 1.2 and <xref ormat="default"/> for (D)TLS 1.2 and <xref target="I-D.ietf-uta-tls13-iot-profil
target="I-D.ietf-uta-tls13-iot-profile"></xref> for DTLS 1.3 e" format="default"/> for DTLS 1.3
recommendations related to IoT devices, and <xref recommendations related to IoT devices, and <xref target="RFC9325" format=
target="RFC9325"></xref> for additional (D)TLS 1.2 recommendations.</t> "default"/> for additional (D)TLS 1.2 recommendations.</t>
<t>A companion YANG module is defined to include a collection of (D)TLS <t>A companion YANG module is defined to include a collection of (D)TLS
parameters and (D)TLS versions maintained by IANA: "iana-tls-profile" parameters and (D)TLS versions maintained by IANA: "iana-tls-profile"
(<xref target="yang-iana"></xref>).</t> (<xref target="yang-iana" format="default"/>).</t>
<t>The (D)TLS parameters in each (D)TLS profile include the <t>The (D)TLS parameters in each (D)TLS profile include the
following:<list style="symbols"> following:</t>
<ul spacing="normal">
<li>
<t>Profile name</t> <t>Profile name</t>
</li>
<li>
<t>(D)TLS versions supported by the IoT device.</t> <t>(D)TLS versions supported by the IoT device.</t>
</li>
<t>List of supported cipher suites (Section 11 of <xref <li>
target="RFC8446"></xref>). For (D)TLS1.2, <xref <t>List of supported cipher suites (<xref target="RFC8446" sectionForm
target="RFC7925"></xref> recommends AEAD ciphers for IoT at="of" section="11"/>). For (D)TLS 1.2, <xref target="RFC7925" format="default"
/> recommends Authenticated Encryption with Associated Data (AEAD) ciphers for I
oT
devices.</t> devices.</t>
</li>
<t>List of supported extension types</t> <li>
<t>List of supported extension types.</t>
</li>
<li>
<t>List of trust anchor certificates used by the IoT device. If the <t>List of trust anchor certificates used by the IoT device. If the
server certificate is signed by one of the trust anchors, the server certificate is signed by one of the trust anchors, the
middlebox continues with the connection as normal. Otherwise, the middlebox continues with the connection as normal. Otherwise, the
middlebox will react as if the server certificate validation has middlebox will react as if the server certificate validation has
failed and takes appropriate action (e.g, block the (D)TLS session). 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 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 certificate (e.g., the private trust anchor can be preloaded at
manufacturing time on the IoT device and the IoT device fetches the manufacturing time on the IoT device and the IoT device fetches the
firmware image from the Firmware server whose certificate is signed firmware image from the firmware server whose certificate is signed
by the private CA). This empowers the middlebox to reject TLS by the private CA). This empowers the middlebox to reject TLS
sessions to servers that the IoT device does not trust.</t> sessions to servers that the IoT device does not trust.</t>
</li>
<t>List of pre-shared key exchange modes</t> <li>
<t>List of pre-shared key exchange modes.</t>
<t>List of named groups (DHE or ECDHE) supported by the client</t> </li>
<li>
<t>List of named groups (DHE or ECDHE) supported by the client.</t>
</li>
<li>
<t>List of signature algorithms the client can validate in X.509 <t>List of signature algorithms the client can validate in X.509
server certificates</t> server certificates.</t>
</li>
<li>
<t>List of signature algorithms the client is willing to accept for th
e
CertificateVerify message (<xref target="RFC8446" sectionFormat="of" s
ection="4.2.3"/>).
<!-- [rfced] May we update this sentence as follows? The "and in TLS
to signal" part is unclear.
<t>List of signature algorithms the client is willing to accept for Original:
CertificateVerify message (Section 4.2.3 of <xref For example, a TLS client implementation can support different sets of
target="RFC8446"></xref>). For example, a TLS client implementation algorithms for certificates and in TLS to signal the capabilities
in "signature_algorithms_cert" and "signature_algorithms"
extensions.
Perhaps:
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.
-->
For example, a TLS client implementation
can support different sets of algorithms for certificates and in TLS can support different sets of algorithms for certificates and in TLS
to signal the capabilities in "signature_algorithms_cert" and to signal the capabilities in "signature_algorithms_cert" and
"signature_algorithms" extensions.</t> "signature_algorithms" extensions.</t>
</li>
<li>
<t>List of supported application protocols (e.g., h3, h2, http/1.1 <t>List of supported application protocols (e.g., h3, h2, http/1.1
etc.)</t> etc.).</t>
</li>
<t>List of certificate compression algorithms (defined in <xref <li>
target="RFC8879"></xref>)</t> <t>List of certificate compression algorithms (defined in <xref target
="RFC8879" format="default"/>).</t>
<t>List of the distinguished names <xref target="X501"></xref> of </li>
<li>
<t>List of the distinguished names <xref target="X501" format="default
"/> of
acceptable certificate authorities, represented in DER-encoded acceptable certificate authorities, represented in DER-encoded
format <xref target="X690"> </xref> (defined in Section 4.2.4 of format <xref target="X690" format="default"> </xref> (defined in <xref
<xref target="RFC8446"></xref>)</t> target="RFC8446" sectionFormat="of" section="4.2.4"/>).</t>
</list></t> </li>
</ul>
<t><xref target="RFC8701">GREASE</xref> defines a mechanism for TLS <t><xref target="RFC8701" format="default">GREASE</xref> defines a mechani
sm for TLS
peers to send random values on TLS parameters to ensure future peers to send random values on TLS parameters to ensure future
extensibility of TLS extensions. Similar random values might be extended extensibility of TLS extensions. Similar random values might be extended
to other TLS parameters. Thus, the (D)TLS profile parameters defined in to other TLS parameters. Thus, the (D)TLS profile parameters defined in
the YANG module by this document MUST NOT include the GREASE values for the YANG module by this document <bcp14>MUST NOT</bcp14> include the GREAS E values for
extension types, named groups, signature algorithms, (D)TLS versions, extension types, named groups, signature algorithms, (D)TLS versions,
pre-shared key exchange modes, cipher suites and for any other TLS pre-shared key exchange modes, cipher suites, and any other TLS
parameters defined in future RFCs.</t> parameters defined in future RFCs.</t>
<t>The (D)TLS profile does not include parameters like compression <t>The (D)TLS profile does not include parameters like compression
methods for data compression, <xref target="RFC9325"></xref> recommends methods for data compression. <xref target="RFC9325" format="default"/> re commends
disabling TLS-level compression to prevent compression-related attacks. disabling TLS-level compression to prevent compression-related attacks.
In TLS 1.3, only the "null" compression method is allowed (Section 4.1.2 In TLS 1.3, only the "null" compression method is allowed (<xref target="R
of <xref target="RFC8446"></xref>).</t> FC8446" sectionFormat="of" section="4.1.2"/>).</t>
<section numbered="true" toc="default">
<section title="Tree Structure of the (D)TLS profile Extension to the ACL <name>Tree Structure of the (D)TLS Profile Extension to the ACL YANG Mod
YANG Model"> ule</name>
<t>This document augments the "ietf-acl" ACL YANG module defined in <t>This document augments the "ietf-acl" ACL YANG module defined in
<xref target="RFC8519"></xref> for signaling the IoT device (D)TLS <xref target="RFC8519" format="default"/> for signaling the IoT device ( D)TLS
profile. This document defines the YANG module "ietf-acl-tls". The profile. This document defines the YANG module "ietf-acl-tls". The
meaning of the symbols in the YANG tree diagram are defined in <xref meaning of the symbols in the YANG tree diagram are defined in <xref tar
target="RFC8340"></xref> and it has the following tree structure:</t> get="RFC8340" format="default"/> and it has the following tree structure:</t>
<sourcecode name="" type="yangtree"><![CDATA[
<t><figure> module: ietf-acl-tls
<artwork><![CDATA[module: ietf-acl-tls
augment /acl:acls/acl:acl/acl:aces/acl:ace/acl:matches: augment /acl:acls/acl:acl/acl:aces/acl:ace/acl:matches:
+--rw client-profiles {match-on-tls-dtls}? +--rw client-profiles {match-on-tls-dtls}?
+--rw tls-dtls-profile* [name] +--rw tls-dtls-profile* [name]
+--rw name string +--rw name string
+--rw supported-tls-version* ianatp:tls-version +--rw supported-tls-version* ianatp:tls-version
+--rw supported-dtls-version* ianatp:dtls-version +--rw supported-dtls-version* ianatp:dtls-version
+--rw cipher-suite* ianatp:cipher-algorithm +--rw cipher-suite* ianatp:cipher-algorithm
+--rw extension-type* +--rw extension-type*
| ianatp:extension-type | ianatp:extension-type
+--rw accept-list-ta-cert* +--rw accept-list-ta-cert*
skipping to change at line 470 skipping to change at line 549
+--rw signature-algorithm* +--rw signature-algorithm*
| ianatp:signature-algorithm | ianatp:signature-algorithm
+--rw application-protocol* +--rw application-protocol*
| ianatp:application-protocol | ianatp:application-protocol
+--rw cert-compression-algorithm* +--rw cert-compression-algorithm*
| ianatp:cert-compression-algorithm | ianatp:cert-compression-algorithm
| {tls13 or dtls13}? | {tls13 or dtls13}?
+--rw certificate-authorities* +--rw certificate-authorities*
certificate-authority certificate-authority
{tls13 or dtls13}? {tls13 or dtls13}?
]]></sourcecode>
]]></artwork>
</figure></t>
</section> </section>
<section anchor="YANG2" numbered="true" toc="default">
<name>The (D)TLS Profile Extension to the ACL YANG Module</name>
<section anchor="YANG2" <!--[rfced] Note that the YANG modules have been updated per the
title="The (D)TLS profile Extension to the ACL YANG Model"> formatting option of pyang. Please let us know any concerns.
<t><figure> -->
<artwork><![CDATA[<CODE BEGINS> file "ietf-acl-tls@2024-01-23.yang"
<!--[rfced] Regarding the contact statement in the ietf-acl-tls
and ietf-mud-tls YANG modules, would you like to add Dan Wing
and Blake Anderson, i.e., to list all authors of this document?
(FYI, Tiru, your name has been updated to match your preference
in past RFCs. Just let us know if updates are needed.)
Current:
Author: Tirumaleswar Reddy.K
kondtir@gmail.com
-->
<sourcecode name="ietf-acl-tls@2025-03-10.yang" type="yang" markers="tru
e"><![CDATA[
module ietf-acl-tls { module ietf-acl-tls {
yang-version 1.1; yang-version 1.1;
namespace "urn:ietf:params:xml:ns:yang:ietf-acl-tls"; namespace "urn:ietf:params:xml:ns:yang:ietf-acl-tls";
prefix acl-tls; prefix acl-tls;
import iana-tls-profile { import iana-tls-profile {
prefix ianatp; prefix ianatp;
reference reference
"RFC XXXX: Manufacturer Usage Description (MUD) (D)TLS "RFC 9761: Manufacturer Usage Description (MUD) for TLS and
Profiles for IoT Devices"; DTLS Profiles for Internet of Things (IoT) Devices";
} }
import ietf-crypto-types { import ietf-crypto-types {
prefix ct; prefix ct;
reference reference
"draft-ietf-netconf-crypto-types: YANG Data Types and Groupings "RFC 9640: YANG Data Types and Groupings for Cryptography";
for Cryptography";
} }
import ietf-access-control-list { import ietf-access-control-list {
prefix acl; prefix acl;
reference reference
"RFC 8519: YANG Data Model for Network Access "RFC 8519: YANG Data Model for Network Access
Control Lists (ACLs)"; Control Lists (ACLs)";
} }
organization organization
"IETF OPSAWG (Operations and Management Area Working Group)"; "IETF OPSAWG (Operations and Management Area Working Group)";
contact contact
"WG Web: <https://datatracker.ietf.org/wg/opsawg/> "WG Web: <https://datatracker.ietf.org/wg/opsawg/>
WG List: opsawg@ietf.org WG List: opsawg@ietf.org
Author: Konda, Tirumaleswar Reddy Author: Tirumaleswar Reddy.K
kondtir@gmail.com kondtir@gmail.com
"; ";
description description
"This YANG module defines a component that augments the "This YANG module defines a component that augments the
IETF description of an access list to allow (D)TLS profile IETF description of an access list to allow (D)TLS profiles
as matching criteria. as matching criteria.
Copyright (c) 2024 IETF Trust and the persons identified as Copyright (c) 2025 IETF Trust and the persons identified as
authors of the code. All rights reserved. authors of the code. All rights reserved.
Redistribution and use in source and binary forms, with or Redistribution and use in source and binary forms, with or
without modification, is permitted pursuant to, and subject without modification, is permitted pursuant to, and subject
to the license terms contained in, the Revised BSD License to the license terms contained in, the Revised BSD License
set forth in Section 4.c of the IETF Trust's Legal Provisions set forth in Section 4.c of the IETF Trust's Legal Provisions
Relating to IETF Documents Relating to IETF Documents
(http://trustee.ietf.org/license-info). (http://trustee.ietf.org/license-info).
This version of this YANG module is part of RFC XXXX; see This version of this YANG module is part of RFC 9761; see
the RFC itself for full legal notices."; the RFC itself for full legal notices.";
revision 2022-10-10 { revision 2025-03-10 {
description description
"Initial revision"; "Initial revision.";
reference reference
"RFC XXXX: Manufacturer Usage Description (MUD) (D)TLS "RFC 9761: Manufacturer Usage Description (MUD) for TLS and
Profiles for IoT Devices"; DTLS Profiles for Internet of Things (IoT) Devices";
} }
feature tls12 { feature tls12 {
description description
"TLS Protocol Version 1.2 is supported."; "TLS Protocol Version 1.2 is supported.";
reference reference
"RFC 5246: The Transport Layer Security (TLS) Protocol "RFC 5246: The Transport Layer Security (TLS) Protocol
Version 1.2"; Version 1.2";
} }
skipping to change at line 566 skipping to change at line 656
"DTLS Protocol Version 1.2 is supported."; "DTLS Protocol Version 1.2 is supported.";
reference reference
"RFC 6347: Datagram Transport Layer Security "RFC 6347: Datagram Transport Layer Security
Version 1.2"; Version 1.2";
} }
feature dtls13 { feature dtls13 {
description description
"DTLS Protocol Version 1.3 is supported."; "DTLS Protocol Version 1.3 is supported.";
reference reference
"RFC 9147: Datagram Transport Layer "RFC 9147: Datagram Transport Layer Security 1.3";
Security 1.3";
} }
feature match-on-tls-dtls { feature match-on-tls-dtls {
description description
"The networking device can support matching on "The networking device can support matching on
(D)TLS parameters."; (D)TLS parameters.";
} }
typedef spki-pin-set { typedef spki-pin-set {
type binary; type binary;
description description
"Subject Public Key Info pin set as discussed in "Subject Public Key Info pin set as discussed in
Section 2.4 of RFC7469."; Section 2.4 of RFC 7469.";
} }
typedef certificate-authority { typedef certificate-authority {
type string; type string;
description description
"Distinguished Name of Certificate authority as discussed "Distinguished Name of Certificate authority as discussed
in Section 4.2.4 of RFC8446."; in Section 4.2.4 of RFC 8446.";
} }
augment "/acl:acls/acl:acl/acl:aces/acl:ace/acl:matches" { augment "/acl:acls/acl:acl/acl:aces/acl:ace/acl:matches" {
if-feature "match-on-tls-dtls"; if-feature "match-on-tls-dtls";
description description
"(D)TLS specific matches."; "(D)TLS specific matches.";
container client-profiles { container client-profiles {
description description
"A grouping for (D)TLS profiles."; "A grouping for (D)TLS profiles.";
list tls-dtls-profile { list tls-dtls-profile {
key "name"; key "name";
description description
"A list of (D)TLS version profiles supported by "A list of (D)TLS version profiles supported by
the client."; the client.";
leaf name { leaf name {
type string { type string {
length "1..64"; length "1..64";
}
description
"The name of (D)TLS profile; space and special
characters are not allowed.";
} }
description leaf-list supported-tls-version {
"The name of (D)TLS profile; space and special type ianatp:tls-version;
characters are not allowed."; description
"TLS versions supported by the client.";
} }
leaf-list supported-tls-version { leaf-list supported-dtls-version {
type ianatp:tls-version;
description
"TLS versions supported by the client.";
}
leaf-list supported-dtls-version {
type ianatp:dtls-version; type ianatp:dtls-version;
description description
"DTLS versions supported by the client."; "DTLS versions supported by the client.";
} }
leaf-list cipher-suite { leaf-list cipher-suite {
type ianatp:cipher-algorithm; type ianatp:cipher-algorithm;
description description
"A list of Cipher Suites supported by the client."; "A list of Cipher Suites supported by the client.";
} }
leaf-list extension-type { leaf-list extension-type {
type ianatp:extension-type; type ianatp:extension-type;
description description
"A list of Extension Types supported by the client."; "A list of Extension Types supported by the client.";
} }
leaf-list accept-list-ta-cert { leaf-list accept-list-ta-cert {
type ct:trust-anchor-cert-cms; type ct:trust-anchor-cert-cms;
description description
"A list of trust anchor certificates used by the client."; "A list of trust anchor certificates used by the
} client.";
leaf-list psk-key-exchange-mode { }
if-feature "tls13 or dtls13"; leaf-list psk-key-exchange-mode {
type ianatp:psk-key-exchange-mode; if-feature "tls13 or dtls13";
description type ianatp:psk-key-exchange-mode;
description
"pre-shared key exchange modes."; "pre-shared key exchange modes.";
} }
leaf-list supported-group { leaf-list supported-group {
type ianatp:supported-group; type ianatp:supported-group;
description description
"A list of named groups supported by the client."; "A list of named groups supported by the client.";
} }
leaf-list signature-algorithm-cert { leaf-list signature-algorithm-cert {
if-feature "tls13 or dtls13"; if-feature "tls13 or dtls13";
type ianatp:signature-algorithm; type ianatp:signature-algorithm;
description description
"A list signature algorithms the client can validate "A list signature algorithms the client can validate
in X.509 certificates."; in X.509 certificates.";
} }
leaf-list signature-algorithm { leaf-list signature-algorithm {
type ianatp:signature-algorithm; type ianatp:signature-algorithm;
description description
"A list signature algorithms the client can validate "A list signature algorithms the client can validate
in the CertificateVerify message."; in the CertificateVerify message.";
} }
leaf-list application-protocol { leaf-list application-protocol {
type ianatp:application-protocol; type ianatp:application-protocol;
description description
"A list application protocols supported by the client."; "A list application protocols supported by the client.";
} }
leaf-list cert-compression-algorithm { leaf-list cert-compression-algorithm {
if-feature "tls13 or dtls13"; if-feature "tls13 or dtls13";
type ianatp:cert-compression-algorithm; type ianatp:cert-compression-algorithm;
description description
"A list certificate compression algorithms "A list certificate compression algorithms
supported by the client."; supported by the client.";
} }
leaf-list certificate-authorities { leaf-list certificate-authorities {
if-feature "tls13 or dtls13"; if-feature "tls13 or dtls13";
type certificate-authority; type certificate-authority;
description description
"A list of the distinguished names of certificate authorities "A list of the distinguished names of certificate
acceptable to the client."; authorities acceptable to the client.";
} }
} }
} }
} }
} }
<CODE ENDS> ]]></sourcecode>
]]></artwork>
</figure></t>
</section> </section>
<section anchor="yang-iana" numbered="true" toc="default">
<name>IANA (D)TLS Profile YANG Module</name>
<section anchor="yang-iana" title="IANA (D)TLS profile YANG Module"> <!-- (Note the URL provided also lead to .txt versions of the registries).
<t>The TLS and DTLS IANA registries are available from <eref
target="https://www.iana.org/assignments/tls-parameters/tls-parameters.t
xt"></eref>
and <eref
target="https://www.iana.org/assignments/tls-extensiontype-values/tls-ex
tensiontype-values.txt"></eref>.
Changes to TLS and DTLS related IANA registries are discussed in <xref
target="RFC8447"></xref>.</t>
<t>The values for all the parameters in the "iana-tls-profile" YANG "Transport Layer Security (TLS) Parameters" registry group (https://www.iana.org
/assignments/tls-parameters/tls-parameters.xhtml)
"Transport Layer Security (TLS) Extensions" registry group (https://www.iana.org
/assignments/tls-extensiontype-values/tls-extensiontype-values.xhtml)
I've included XML for references to these registry groups below:
XML for "Transport Layer Security (TLS) Parameters" registry group
(Note: needs cite tag/reference anchor)
<reference anchor="" target="https://www.iana.org/assignments/tls-parameters">
<front>
<title>Transport Layer Security (TLS) Parameters</title>
<author>
<organization>IANA</organization>
</author>
</front>
</reference>
XML for "Transport Layer Security (TLS) Extensions" registry group
(Note: needs cite tag/reference anchor)
<reference anchor="" target="https://www.iana.org/assignments/tls-extensiontyp
e-values">
<front>
<title>Transport Layer Security (TLS) Extensions</title>
<author>
<organization>IANA</organization>
</author>
</front>
</reference>
-->
<t>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-val
ues" brackets="angle" />.
Changes to TLS- and DTLS-related IANA registries are discussed in <xref
target="RFC8447" format="default"/>.</t>
<t>The values for all the parameters in the "iana-tls-profile" YANG
module are defined in the TLS and DTLS IANA registries excluding the module are defined in the TLS and DTLS IANA registries excluding the
tls-version, dtls-version, spki-pin-set, and certificate-authority tls-version, dtls-version, spki-pin-set, and certificate-authority
parameters. The values of 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> parameters will be specific to the IoT device.</t>
<t>The TLS and DTLS IANA registries do not maintain (D)TLS version <t>The TLS and DTLS IANA registries do not maintain (D)TLS version
numbers. In (D)TLS 1.2 and below, "legacy_version" field in the numbers. In (D)TLS 1.2 and below, the "legacy_version" field in the
ClientHello message is used for version negotiation. However, in ClientHello message is used for version negotiation. However, in
(D)TLS 1.3, the "supported_versions" extension is used by the client (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 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 messages are identified as having a "legacy_version" of 0x0303 and a
"supported_versions" extension present with 0x0304 as the highest "supported_versions" extension present with 0x0304 as the highest
version. DTLS 1.3 ClientHello messages are identified as having a version. DTLS 1.3 ClientHello messages are identified as having a
"legacy_version" of 0xfefd and a "supported_versions" extension "legacy_version" of 0xfefd and a "supported_versions" extension
present with 0x0304 as the highest version.</t> present with 0x0304 as the highest version.</t>
<t>In order to ease updating the "iana-tls-profile" YANG module with <t>In order to ease updating the "iana-tls-profile" YANG module with
future (D)TLS versions, new (D)TLS version registries are defined in future (D)TLS versions, new (D)TLS version registries are defined in
<xref target="tls-registry"></xref> and <xref <xref target="tls-registry" format="default"/> and <xref target="dtls-re
target="dtls-registry"></xref>. Whenever a new (D)TLS protocol version gistry" format="default"/>. Whenever a new (D)TLS protocol version
is defined, the registry will be updated using expert review; the is defined, the registry will be updated using expert review; the
"iana-tls-profile" YANG module will be automatically updated by "iana-tls-profile" YANG module will be automatically updated by
IANA.</t> IANA.</t>
<t>Implementers or users of this specification must refer to the <t>Implementers or users of this specification must refer to the
IANA-maintained "iana-tls-profile" YANG module available at XXXX [Note IANA-maintained "iana-tls-profile" YANG module available at <eref target
to RFC Editor to replace "XXXX" with the URL link of the ="https://www.iana.org/assignments/yang-parameters" brackets="angle"/>.</t>
IANA-maintained "iana-tls-profile" YANG module].</t>
<t>The initial version of the "iana-tls-profile" YANG module is <t>The initial version of the "iana-tls-profile" YANG module is
defined as follows:</t> defined as follows:</t>
<t><figure> <sourcecode name="iana-tls-profile@2025-03-10.yang" type="yang" markers=
<artwork><![CDATA[<CODE BEGINS> file "iana-tls-profile@2024-01-23.ya "true"><![CDATA[
ng"
module iana-tls-profile { module iana-tls-profile {
yang-version 1.1; yang-version 1.1;
namespace "urn:ietf:params:xml:ns:yang:iana-tls-profile"; namespace "urn:ietf:params:xml:ns:yang:iana-tls-profile";
prefix ianatp; prefix ianatp;
organization organization
"IANA"; "IANA";
contact contact
" Internet Assigned Numbers Authority " Internet Assigned Numbers Authority
Postal: ICANN Postal: ICANN
12025 Waterfront Drive, Suite 300 12025 Waterfront Drive, Suite 300
Los Angeles, CA 90094-2536 Los Angeles, CA 90094-2536
United States United States
Tel: +1 310 301 5800 Tel: +1 310 301 5800
E-Mail: iana@iana.org>"; Email: iana@iana.org>";
description description
"This module contains YANG definition for the (D)TLS profile. "This module contains the YANG definition for the (D)TLS profile.
Copyright (c) 2024 IETF Trust and the persons identified as Copyright (c) 2025 IETF Trust and the persons identified as
authors of the code. All rights reserved. authors of the code. All rights reserved.
Redistribution and use in source and binary forms, with or Redistribution and use in source and binary forms, with or
without modification, is permitted pursuant to, and subject without modification, is permitted pursuant to, and subject
to the license terms contained in, the Revised BSD License to the license terms contained in, the Revised BSD License
set forth in Section 4.c of the IETF Trust's Legal Provisions set forth in Section 4.c of the IETF Trust's Legal Provisions
Relating to IETF Documents Relating to IETF Documents
(http://trustee.ietf.org/license-info). (http://trustee.ietf.org/license-info).
All revisions of IETF and IANA published modules can be found All revisions of IETF and IANA published modules can be found
at the YANG Parameters registry at the YANG Parameters registry
(https://www.iana.org/assignments/yang-parameters). (https://www.iana.org/assignments/yang-parameters).
The initial version of this YANG module is part of RFC XXXX; The initial version of this YANG module is part of RFC 9761;
see the RFC itself for full legal notices. see the RFC itself for full legal notices.
// RFC Ed.: replace the IANA_TLS-PROFILE_URL and remove this note
The latest version of this YANG module is available at The latest version of this YANG module is available at
<IANA_TLS-PROFILE_URL>."; https://www.iana.org/assignments/yang-parameters.";
revision 2024-01-23 { revision 2025-03-10 {
description description
"Initial revision"; "Initial revision.";
reference reference
"RFC XXXX: Manufacturer Usage Description (MUD) (D)TLS Profiles "RFC 9761: Manufacturer Usage Description (MUD) for TLS and
for IoT Devices"; DTLS Profiles for Internet of Things (IoT) Devices";
} }
typedef extension-type { typedef extension-type {
type uint16; type uint16;
description description
"Extension type in the TLS ExtensionType Values registry as "Extension type in the TLS ExtensionType Values registry as
defined in Section 7 of RFC8447."; defined in Section 7 of RFC 8447.";
} }
typedef supported-group { typedef supported-group {
type uint16; type uint16;
description description
"Supported Group in the TLS Supported Groups registry as "Supported Group in the TLS Supported Groups registry as
defined in Section 9 of RFC8447."; defined in Section 9 of RFC 8447.";
} }
typedef signature-algorithm { typedef signature-algorithm {
type uint16; type uint16;
description description
"Signature algorithm in the TLS SignatureScheme registry as "Signature algorithm in the TLS SignatureScheme registry as
defined in Section 11 of RFC8446."; defined in Section 11 of RFC 8446.";
} }
typedef psk-key-exchange-mode { typedef psk-key-exchange-mode {
type uint8; type uint8;
description description
"Pre-shared key exchange mode in the TLS PskKeyExchangeMode "Pre-shared key exchange mode in the TLS PskKeyExchangeMode
registry as defined in Section 11 of RFC8446."; registry as defined in Section 11 of RFC 8446.";
} }
typedef application-protocol { typedef application-protocol {
type string; type string;
description description
"Application-Layer Protocol Negotiation (ALPN) Protocol ID "Application-Layer Protocol Negotiation (ALPN) Protocol ID
registry as defined in Section 6 of RFC7301."; registry as defined in Section 6 of RFC 7301.";
} }
typedef cert-compression-algorithm { typedef cert-compression-algorithm {
type uint16; type uint16;
description description
"Certificate compression algorithm in TLS Certificate "Certificate compression algorithm in TLS Certificate
Compression Algorithm IDs registry as defined in Compression Algorithm IDs registry as defined in
Section 7.3 of RFC8879."; Section 7.3 of RFC 8879.";
} }
typedef cipher-algorithm { typedef cipher-algorithm {
type uint16; type uint16;
description description
"Cipher suite in TLS Cipher Suites registry "Cipher suite in TLS Cipher Suites registry
as discussed in Section 11 of RFC8446."; as discussed in Section 11 of RFC 8446.";
} }
typedef tls-version { typedef tls-version {
type enumeration { type enumeration {
enum tls12 { enum tls12 {
value 1; value 1;
description description
"TLS Protocol Version 1.2. "TLS Protocol Version 1.2.
TLS 1.2 ClientHello contains TLS 1.2 ClientHello contains
skipping to change at line 890 skipping to change at line 1000
contained in its body and the ClientHello contains contained in its body and the ClientHello contains
0xfefd in 'legacy_version'."; 0xfefd in 'legacy_version'.";
reference reference
"RFC 9147: Datagram Transport Layer Security 1.3"; "RFC 9147: Datagram Transport Layer Security 1.3";
} }
} }
description description
"Indicates the DTLS version."; "Indicates the DTLS version.";
} }
} }
<CODE ENDS> ]]></sourcecode>
]]></artwork>
</figure></t>
</section> </section>
<section anchor="mud-dtls-extension" numbered="true" toc="default">
<section anchor="mud-dtls-extension" <name>MUD (D)TLS Profile Extension</name>
title="MUD (D)TLS Profile Extension">
<t>This document augments the "ietf-mud" MUD YANG module to indicate <t>This document augments the "ietf-mud" MUD YANG module to indicate
whether the device supports (D)TLS profile. If the "ietf-mud-tls" whether the device supports (D)TLS profile. If the "ietf-mud-tls"
extension is supported by the device, MUD file is assumed to implement extension is supported by the device, MUD file is assumed to implement
the "match-on-tls-dtls" ACL model feature defined in this the "match-on-tls-dtls" ACL model feature defined in this
specification. Furthermore, only "accept" or "drop" actions SHOULD be specification. Furthermore, only "accept" or "drop" actions <bcp14>SHOUL D</bcp14> be
included with the (D)TLS profile similar to the actions allowed in included with the (D)TLS profile similar to the actions allowed in
Section 2 of <xref target="RFC8520"></xref>.</t> <xref target="RFC8520" sectionFormat="of" section="2"/>.</t>
<t>This document defines the YANG module "ietf-mud-tls", which has the <t>This document defines the YANG module "ietf-mud-tls", which has the
following tree structure:</t> following tree structure:</t>
<t><figure> <sourcecode name="" type="yangtree"><![CDATA[
<artwork><![CDATA[module: ietf-mud-tls module: ietf-mud-tls
augment /ietf-mud:mud: augment /ietf-mud:mud:
+--rw is-tls-dtls-profile-supported? boolean +--rw is-tls-dtls-profile-supported? boolean
]]></artwork> ]]></sourcecode>
</figure></t>
<t>The model is defined as follows:</t> <t>The model is defined as follows:</t>
<sourcecode name="ietf-mud-tls@2025-03-10.yang" type="yang" markers="tru
<t><figure> e"><![CDATA[
<artwork><![CDATA[<CODE BEGINS> file "ietf-mud-tls@2020-10-20.yang"
module ietf-mud-tls { module ietf-mud-tls {
yang-version 1.1; yang-version 1.1;
namespace "urn:ietf:params:xml:ns:yang:ietf-mud-tls"; namespace "urn:ietf:params:xml:ns:yang:ietf-mud-tls";
prefix ietf-mud-tls; prefix ietf-mud-tls;
import ietf-mud { import ietf-mud {
prefix ietf-mud; prefix ietf-mud;
reference reference
"RFC 8520: Manufacturer Usage Description Specification"; "RFC 8520: Manufacturer Usage Description Specification";
} }
organization organization
"IETF OPSAWG (Operations and Management Area Working Group)"; "IETF OPSAWG (Operations and Management Area Working Group)";
contact contact
"WG Web: <https://datatracker.ietf.org/wg/opsawg/> "WG Web: <https://datatracker.ietf.org/wg/opsawg/>
WG List: opsawg@ietf.org WG List: opsawg@ietf.org
Author: Konda, Tirumaleswar Reddy Author: Tirumaleswar Reddy.K
kondtir@gmail.com kondtir@gmail.com
"; ";
description description
"Extension to a MUD module to indicate (D)TLS "Extension to a MUD module to indicate (D)TLS
profile support. profile support.
Copyright (c) 2024 IETF Trust and the persons identified as Copyright (c) 2025 IETF Trust and the persons identified as
authors of the code. All rights reserved. authors of the code. All rights reserved.
Redistribution and use in source and binary forms, with or Redistribution and use in source and binary forms, with or
without modification, is permitted pursuant to, and subject without modification, is permitted pursuant to, and subject
to the license terms contained in, the Revised BSD License to the license terms contained in, the Revised BSD License
set forth in Section 4.c of the IETF Trust's Legal Provisions set forth in Section 4.c of the IETF Trust's Legal Provisions
Relating to IETF Documents Relating to IETF Documents
(http://trustee.ietf.org/license-info). (http://trustee.ietf.org/license-info).
This version of this YANG module is part of RFC XXXX; see This version of this YANG module is part of RFC 9761; see
the RFC itself for full legal notices."; the RFC itself for full legal notices.";
revision 2022-10-10 { revision 2025-03-10 {
description description
"Initial revision."; "Initial revision.";
reference reference
"RFC XXXX: Manufacturer Usage Description (MUD) (D)TLS "RFC 9761: Manufacturer Usage Description (MUD) for TLS and
Profiles for IoT Devices"; DTLS Profiles for Internet of Things (IoT)
} Devices";
}
augment "/ietf-mud:mud" { augment "/ietf-mud:mud" {
description description
"This adds an extension for a manufacturer "This adds an extension for a manufacturer
to indicate whether the (D)TLS profile is to indicate whether the (D)TLS profile is
supported by a device."; supported by a device.";
leaf is-tls-dtls-profile-supported { leaf is-tls-dtls-profile-supported {
type boolean; type boolean;
default false; default "false";
description description
"This value will equal 'true' if a device supports "This value will equal 'true' if a device supports
(D)TLS profile."; (D)TLS profile.";
} }
} }
} }
<CODE ENDS> ]]></sourcecode>
]]></artwork>
</figure></t>
</section> </section>
</section> </section>
<section anchor="processing" numbered="true" toc="default">
<section anchor="processing" title="Processing of the MUD (D)TLS Profile"> <name>Processing of the MUD (D)TLS Profile</name>
<t>The following text outlines the rules for a network security service <t>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 (e.g., firewall) to follow to process the MUD (D)TLS Profile so as to
avoid ossification:</t> avoid ossification:</t>
<ul spacing="normal">
<t><list style="symbols"> <li>
<t>If the (D)TLS parameter observed in a (D)TLS session is not <t>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 specified in the MUD (D)TLS profile and the parameter is recognized
by the firewall, it can identify unexpected (D)TLS usage, which can by the firewall, it can identify unexpected (D)TLS usage, which can
indicate the presence of unauthorized software or malware on an indicate the presence of unauthorized software or malware on an
endpoint. The firewall can take several actions like block the endpoint. The firewall can take several actions, such as blocking the
(D)TLS session or raise an alert to quarantine and remediate the (D)TLS session or raising an alert to quarantine and remediate the
compromised device. For example, if the cipher suite compromised device. For example, if the cipher suite
TLS_RSA_WITH_AES_128_CBC_SHA in the ClientHello message is not 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 specified in the MUD (D)TLS profile and the cipher suite is
recognized by the firewall, it can identify unexpected TLS recognized by the firewall, it can identify unexpected TLS
usage.</t> usage.</t>
</li>
<li>
<t>If the (D)TLS parameter observed in a (D)TLS session is not <t>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 specified in the MUD (D)TLS profile and the (D)TLS parameter is not
recognized by the firewall, it can ignore the unrecognized parameter recognized by the firewall, it can ignore the unrecognized parameter
and the correct behavior is not to block the (D)TLS session. The and the correct behavior is not to block the (D)TLS session. The
behaviour is functionally equivalent to the compliant TLS middlebox behavior is functionally equivalent to the compliant TLS middlebox
description in Section 9.3 of <xref target="RFC8446"></xref> to description in <xref target="RFC8446" sectionFormat="of" section="9.3"
/> to
ignore all unrecognized cipher suites, extensions, and other ignore all unrecognized cipher suites, extensions, and other
parameters. For example, if the cipher suite parameters. For example, if the cipher suite
TLS_CHACHA20_POLY1305_SHA256 in the ClientHello message is not TLS_CHACHA20_POLY1305_SHA256 in the ClientHello message is not
specified in the MUD (D)TLS profile and the cipher suite 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 recognized by the firewall, it can ignore the unrecognized cipher
suite. This rule also ensures that the network security service will suite. This rule also ensures that the network security service will
ignore the GREASE values advertised by TLS peers and interoperate ignore the GREASE values advertised by TLS peers and interoperate
with the implementations advertising GREASE values.</t> with the implementations advertising GREASE values.</t>
</li>
<li>
<t>Deployments update at different rates, so an updated MUD (D)TLS <t>Deployments update at different rates, so an updated MUD (D)TLS
profile may support newer parameters. If the firewall does not profile may support newer parameters. If the firewall does not
recognize the newer parameters, an alert should be triggered to the recognize the newer parameters, an alert should be triggered to the
firewall vendor and the IoT device owner or administrator. A firewall vendor and the IoT device owner or administrator. A
firewall must be readily updatable, so that when new parameters in firewall must be readily updatable so that when new parameters in
the MUD (D)TLS profile are discovered that are not recognized by the the MUD (D)TLS profile are discovered that are not recognized by the
firewall, it can be updated quickly. Most importantly, if the firewall, it can be updated quickly. Most importantly, if the
firewall is not readily updatable, its protection efficacy to firewall is not readily updatable, its protection efficacy to
identify emerging malware will decrease with time. For example, if identify emerging malware will decrease with time. For example, if
the cipher suite TLS_AES_128_CCM_8_SHA256 specified in the MUD 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 (D)TLS profile is not recognized by the firewall, an alert will be
triggered. Similarly, if the (D)TLS version specified in the MUD triggered. Similarly, if the (D)TLS version specified in the MUD
file is not recognized by the firewall, an alert will be file is not recognized by the firewall, an alert will be
triggered.</t> triggered.</t>
</li>
<li>
<t>If the MUD (D)TLS profile includes any parameters that are <t>If the MUD (D)TLS profile includes any parameters that are
susceptible to attacks (e.g., weaker cryptographic parameters), an susceptible to attacks (e.g., weaker cryptographic parameters), an
alert MUST be triggered to the firewall vendor and the IoT device alert <bcp14>MUST</bcp14> be triggered to the firewall vendor and the IoT device
owner or administrator.</t> owner or administrator.</t>
</list></t> </li>
</ul>
</section> </section>
<section anchor="Example" numbered="true" toc="default">
<section anchor="Example" title="MUD File Example"> <name>MUD File Example</name>
<t>The example below contains (D)TLS profile parameters for a IoT device <t>The example below contains (D)TLS profile parameters for an IoT device
used to reach servers listening on port 443 using TCP transport. JSON used to reach servers listening on port 443 using TCP transport. JSON
encoding of YANG modelled data <xref target="RFC7951"></xref> is used to encoding of YANG-modeled data <xref target="RFC7951" format="default"/> is used to
illustrate the example.</t> illustrate the example.</t>
<!-- [rfced] Please review the "type" attribute of each sourcecode element
<t><figure> in the XML file to ensure correctness. If the current list of preferred
<artwork><![CDATA[{ values for "type"
(https://www.rfc-editor.org/rpc/wiki/doku.php?id=sourcecode-types)
does not contain an applicable type, then feel free to let us know.
Also, it is acceptable to leave the "type" attribute not set.
-->
<sourcecode name="" type=""><![CDATA[{
"ietf-mud:mud": { "ietf-mud:mud": {
"mud-version": 1, "mud-version": 1,
"mud-url": "https://example.com/IoTDevice", "mud-url": "https://example.com/IoTDevice",
"last-update": "2024-08-05T03:56:40.105+10:00", "last-update": "2024-08-05T03:56:40.105+10:00",
"cache-validity": 100, "cache-validity": 100,
"extensions": [ "extensions": [
"ietf-mud-tls" "ietf-mud-tls"
], ],
"ietf-mud-tls:is-tls-dtls-profile-supported": "true", "ietf-mud-tls:is-tls-dtls-profile-supported": "true",
"is-supported": true, "is-supported": true,
skipping to change at line 1112 skipping to change at line 1222
} }
} }
} }
] ]
} }
} }
] ]
} }
} }
} }
]]></artwork> ]]></sourcecode>
</figure></t>
<t>The following illustrates the example scenarios for processing the <t>The following illustrates the example scenarios for processing the
above profile:<list style="symbols"> above profile:</t>
<t>If the extension type "encrypt_then_mac" (code point 22) <xref <ul spacing="normal">
target="RFC7366"></xref> in the ClientHello message is recognized by <li>
<t>If the extension type "encrypt_then_mac" (code point 22) <xref targ
et="RFC7366" format="default"/> in the ClientHello message is recognized by
the firewall, it can identify unexpected TLS usage.</t> the firewall, it can identify unexpected TLS usage.</t>
</li>
<t>If the extension type "token_binding" (code point 24) <xref <li>
target="RFC8472"></xref> in the MUD (D)TLS profile is not recognized <t>If the extension type "token_binding" (code point 24) <xref target=
"RFC8472" format="default"/> in the MUD (D)TLS profile is not recognized
by the firewall, it can ignore the unrecognized extension. Because by the firewall, it can ignore the unrecognized extension. Because
the extension type "token_binding" is specified in the profile, an the extension type "token_binding" is specified in the profile, an
alert will be triggered to the firewall vendor and the IoT device 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> owner or administrator to notify the firewall is not up-to-date.</t>
</li>
<li>
<t>The two-byte values assigned by IANA for the cipher suites <t>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 TLS_AES_128_GCM_SHA256 and TLS_AES_256_GCM_SHA384 are represented in
decimal format.</t> decimal format.</t>
</list></t> </li>
</ul>
</section> </section>
<section anchor="ACL" numbered="true" toc="default">
<name>Software-Based ACLs and ACLs Within a (D)TLS 1.3 Proxy</name>
<!--[rfced] Is the expansion of TCAM accurate here?
(It was plural in the original; it is not plural currently.)
<section anchor="ACL" Original:
title="Software-Based ACLs and ACLs within a (D)TLS 1.3 Proxy"> While ACL technology is traditionally associated with fixed-length
bit matching in hardware implementations, such as those found in
TCAMs, the use of ACLs in software, ...
Current:
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, ...
-->
<t>While ACL technology is traditionally associated with fixed-length <t>While ACL technology is traditionally associated with fixed-length
bit matching in hardware implementations, such as those found in TCAMs, bit matching in hardware implementations, such as those found in Ternary C ontent-Addressable Memory (TCAM),
the use of ACLs in software, like with iptables, allows for more the use of ACLs in software, like with iptables, allows for more
flexible matching criteria, including string matching. In the context of flexible matching criteria, including string matching. In the context of
MUD (D)TLS profiles, the ability to match binary data and strings is a MUD (D)TLS profiles, the ability to match binary data and strings is a
deliberate choice, made to leverage the capabilities of software-based deliberate choice made to leverage the capabilities of software-based
ACLs. This enables more dynamic and context-sensitive access control, ACLs. This enables more dynamic and context-sensitive access control,
which is essential for the intended application of MUD. The DNS which is essential for the intended application of MUD. The DNS
extension added to ACL in MUD specification <xref extension added to ACL in the MUD specification <xref target="RFC8520" for
target="RFC8520"></xref> also require software-based ACLs.</t> mat="default"/> also requires software-based ACLs.</t>
<t>Regarding the use of MUD (D)TLS ACL in a (D)TLS 1.3 proxy, the goal <t>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 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 ACL rules. This implies that MUD (D)TLS ACL matching would need to occur
after decrypting the encrypted TLS handshake messages within the proxy. after decrypting the encrypted TLS handshake messages within the proxy.
The proxy would inspect the handshake fields according to the MUD The proxy would inspect the handshake fields according to the MUD
profile. ACL matching would be performed in two stages: first, by profile.
<!-- [rfced] May this sentence be updated as follows?
Should the "messages" be singular to match the first stage?
Original:
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.
Perhaps (if singular):
ACL matching would be performed in two stages:
first, by filtering the clear-text TLS handshake message; second, by
filtering after decrypting the TLS handshake message.
Or (if singular, and putting the steps of the second stage in order):
ACL matching would be performed in two stages:
first, by filtering the clear-text TLS handshake message; second, by
decrypting the TLS handshake message then filtering it once more.
-->
ACL matching would be performed in two stages: first, by
filtering clear-text TLS handshake message and second, by filtering filtering clear-text TLS handshake message and second, by filtering
after decrypting the TLS handshake messages.</t> after decrypting the TLS handshake messages.</t>
</section> </section>
<section anchor="Security" numbered="true" toc="default">
<section anchor="Security" title="Security Considerations"> <name>Security Considerations</name>
<t>Security considerations in <xref target="RFC8520"></xref> need to be <t>Security considerations in <xref target="RFC8520" format="default"/> ne
taken into consideration. The middlebox MUST adhere to the invariants ed to be
discussed in Section 9.3 of <xref target="RFC8446"></xref> to act as a taken into consideration. The middlebox <bcp14>MUST</bcp14> adhere to the
invariants
discussed in <xref target="RFC8446" sectionFormat="of" section="9.3"/> to
act as a
compliant proxy.</t> compliant proxy.</t>
<t>Although it is challenging for malware to mimic the TLS behavior of <t>Although it is challenging for malware to mimic the TLS behavior of
various IoT device types and models from different manufacturers, there various IoT device types and models from different manufacturers, there
is still a potential for malicious agents to use similar (D)TLS profile is still a potential for malicious agents to use similar (D)TLS profile
parameters as legitimate devices to evade detection. This difficulty parameters as legitimate devices to evade detection. This difficulty
arises because IoT devices often have distinct (D)TLS profiles between arises because IoT devices often have distinct (D)TLS profiles between
models and especially between manufacturers. While malware may find it models and especially between manufacturers. While malware may find it
hard to perfectly replicate the TLS behavior across such diverse hard to perfectly replicate the TLS behavior across such diverse
devices, it is not impossible. Malicious agents might manage to use devices, it is not impossible. Malicious agents might manage to use
(D)TLS profile parameters that resemble those of legitimate devices. The (D)TLS profile parameters that resemble those of legitimate devices. The
feasibility of this depends on the nature of the profile parameters; for feasibility of this depends on the nature of the profile parameters; for
skipping to change at line 1178 skipping to change at line 1318
models and especially between manufacturers. While malware may find it models and especially between manufacturers. While malware may find it
hard to perfectly replicate the TLS behavior across such diverse hard to perfectly replicate the TLS behavior across such diverse
devices, it is not impossible. Malicious agents might manage to use devices, it is not impossible. Malicious agents might manage to use
(D)TLS profile parameters that resemble those of legitimate devices. The (D)TLS profile parameters that resemble those of legitimate devices. The
feasibility of this depends on the nature of the profile parameters; for feasibility of this depends on the nature of the profile parameters; for
instance, parameters like certificate authorities are complex to mimic, instance, parameters like certificate authorities are complex to mimic,
while others, such as signature algorithms, may be easier to replicate. while others, such as signature algorithms, may be easier to replicate.
The difficulty in mimicking these profiles correlates with the The difficulty in mimicking these profiles correlates with the
specificity of the profiles and the variability in parameters used by specificity of the profiles and the variability in parameters used by
different devices.</t> different devices.</t>
<t>Network security services should also rely on contextual network data <t>Network security services should also rely on contextual network data
(e.g., domain name, IP address etc) to detect false negatives. For (e.g., domain name, IP address, etc.) to detect false negatives. For
example, network security services filter malcious domain names and example, network security services filter malicious domain names and
destination IP addresses with bad reputation score. Further, In order to destination IP addresses with a bad reputation score. Furthermore, in orde
r to
detect such malicious flows, anomaly detection (deep learning techniques detect such malicious flows, anomaly detection (deep learning techniques
on network data) can be used to detect malicious agents using the same on network data) can be used to detect malicious agents using the same
(D)TLS profile parameters as legitimate agent on the IoT device. In (D)TLS profile parameters as the legitimate agent on the IoT device. In
anomaly detection, the main idea is to maintain rigorous learning of anomaly detection, the main idea is to maintain rigorous learning of
"normal" behavior and where an "anomaly" (or an attack) is identified "normal" behavior and where an "anomaly" (or an attack) is identified
and categorized based on the knowledge about the normal behavior and a and categorized based on the knowledge about the normal behavior and a
deviation from this normal behavior. Network security vendors leverage deviation from this normal behavior. Network security vendors leverage
TLS parameters and contextual network data to identify malware (for TLS parameters and contextual network data to identify malware (for
example, see <xref target="eve"></xref>).</t> example, see <xref target="EVE" format="default"/>).</t>
<t>The efficacy of identifying malware in (D)TLS 1.3 flows will be <t>The efficacy of identifying malware in (D)TLS 1.3 flows will be
significantly reduced without leveraging contextual network data or significantly reduced without leveraging contextual network data or
acting as a proxy, as the encryption in (D)TLS 1.3 obscures many of the 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> handshake details that could otherwise be used for detection.</t>
<section numbered="true" toc="default">
<section title="Challenges in Mimicking (D)TLS 1.2 Handshakes for IoT Devi <name>Challenges in Mimicking (D)TLS 1.2 Handshakes for IoT Devices</nam
ces"> e>
<t>(D)TLS 1.2 generally does not require a proxy, as all fields in the <t>(D)TLS 1.2 generally does not require a proxy, as all fields in the
(D)TLS profile are transmitted in clear text during the handshake. (D)TLS profile are transmitted in cleartext during the handshake.
While it is technically possible for an attacker to observe and mimic While it is technically possible for an attacker to observe and mimic
the handshake, an attacker would need to use a domain name and the handshake, an attacker would need to use a domain name and
destination IP address with a good reputation, obtain certificates destination IP address with a good reputation, obtain certificates
from the same CAs used by the IoT devices, and evade traffic analysis from the same CAs used by the IoT devices, and evade traffic analysis
tecniques (e.g., <xref target="eve"></xref>, which detects malicious techniques (e.g., <xref target="EVE" format="default"/>, which detects
patterns in encrypted traffic without decryption). This task is malicious patterns in encrypted traffic without decryption). This task
particularly challenging because IoT devices often have distinct is particularly challenging because IoT devices often have distinct
(D)TLS profiles, varying between models and manufacturers. Unlike the (D)TLS profiles that vary between models and manufacturers. Unlike the
developers of legitimate applications, malware authors are under developers of legitimate applications, malware authors are under
additional constraints such as avoiding any noticeable differences on additional constraints, such as avoiding any noticeable differences on
the infected devices and the potential for take-down requests the infected devices and the potential for take-down requests
impacting their server infrastructure (e.g., certificate revocation by impacting their server infrastructure (e.g., certificate revocation by
a CA upon reporting).</t> a CA upon reporting).</t>
</section> </section>
<section numbered="true" toc="default">
<name>Considerations for the "iana-tls-profile" Module</name>
<t>This section follows the template defined in <xref target="I-D.ietf-n
etmod-rfc8407bis" sectionFormat="of" section="3.7.1"/>.</t>
<section title="Considerations for the &quot;iana-tls-profile&quot; Module <!-- [rfced] Because of your note that the template in rfc8407bis
"> has been used, we will update this paragraph (which appears in Sections
<t>This section follows the template defined in Section 3.7.1 of <xref 9.2, 9.3, and 9.4) to match Section 3.7.1 of rfc8407bis as follows.
target="I-D.ietf-netmod-rfc8407bis"></xref>.</t> Please let us know if that is not what you intended.
<t>The YANG module specified in this document defines a schema for Original:
This section follows the template defined in Section 3.7.1 of
[I-D.ietf-netmod-rfc8407bis].
The YANG module specified in this document defines a schema for data
can possibly be accessed via network management protocols such as
NETCONF [RFC6241] or RESTCONF [RFC8040]. These network management
protocols are required to use a secure transport layer and mutual
authentication, e.g., SSH [RFC6242] without the "none" authentication
option, Transport Layer Security (TLS) [RFC8446] with mutual X.509
authentication, and HTTPS with HTTP authentication (Section 11 of
[RFC9110]).
The Network Access Control Model (NACM) [RFC8341] provides the means
to restrict access for particular users to a pre-configured subset of
all available protocol operations and content.
Perhaps (following draft-ietf-netmod-rfc8407bis-22):
This section follows the template defined in Section 3.7.1 of
[YANG-GUIDELINES].
The "iana-tls-profile" YANG module defines a data model that is
designed to be accessed via YANG-based management protocols, such as
NETCONF [RFC6241] and RESTCONF [RFC8040]. These protocols have to
use a secure transport layer (e.g., SSH [RFC4252], TLS [RFC8446], and
QUIC [RFC9000]) and have to use mutual authentication.
The Network Configuration Access Control Model (NACM) [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.
-->
<!-- DNE -->
<t>The "iana-tls-profile" YANG module specified in this document defines a schem
a for
data can possibly be accessed via network management protocols such as data can possibly be accessed via network management protocols such as
NETCONF <xref target="RFC6241"></xref> or RESTCONF <xref NETCONF <xref target="RFC6241" format="default"/> or RESTCONF <xref targ
target="RFC8040"></xref>. These network management protocols are et="RFC8040" format="default"/>. These network management protocols are
required to use a secure transport layer and mutual authentication, required to use a secure transport layer and mutual authentication,
e.g., SSH <xref target="RFC6242"></xref> without the "none" e.g., SSH <xref target="RFC6242" format="default"/> without the "none"
authentication option, Transport Layer Security (TLS) <xref authentication option, Transport Layer Security (TLS) <xref target="RFC8
target="RFC8446"></xref> with mutual X.509 authentication, and HTTPS 446" format="default"/> with mutual X.509 authentication, and HTTPS
with HTTP authentication (Section 11 of <xref with HTTP authentication (<xref target="RFC9110" sectionFormat="of" sect
target="RFC9110"></xref>).</t> ion="11"/>).</t>
<t>The Network Access Control Model (NACM) <xref target="RFC8341" format
<t>The Network Access Control Model (NACM) <xref ="default"/> provides the means to restrict access for
target="RFC8341"></xref> provides the means to restrict access for
particular users to a pre-configured subset of all available protocol particular users to a pre-configured subset of all available protocol
operations and content.</t> operations and content.</t>
<!-- DNE -->
<t>This YANG module defines YANG enumerations, for a public IANA- <t>This YANG module defines YANG enumerations for a public IANA-
maintained registry.</t> maintained registry.</t>
<t>YANG enumerations are not security-sensitive, as they are <t>YANG enumerations are not security-sensitive, as they are
statically defined in the publicly-accessible YANG module. IANA MAY statically defined in the publicly-accessible YANG module. IANA <bcp14>M AY</bcp14>
deprecate and/or obsolete enumerations over time as needed to address deprecate and/or obsolete enumerations over time as needed to address
security issues.</t> security issues.</t>
<t>This module does not define any writable-nodes, RPCs, actions, or <t>This module does not define any writable-nodes, RPCs, actions, or
notifications, and thus the security consideration for such is not notifications, and thus the security consideration for such is not
provided here.</t> provided here.</t>
</section> </section>
<section numbered="true" toc="default">
<section title="Considerations for the &quot;ietf-acl-tls&quot; Module"> <name>Considerations for the "ietf-acl-tls" Module</name>
<t>This section follows the template defined in Section 3.7.1 of <xref <t>This section follows the template defined in <xref target="I-D.ietf-n
target="I-D.ietf-netmod-rfc8407bis"></xref>.</t> etmod-rfc8407bis" sectionFormat="of" section="3.7.1"/>.</t>
<!-- DNE -->
<t>The YANG module specified in this document defines a schema for <t>The "ietf-acl-tls" YANG module specified in this document defines a s
chema for
data that is designed to be accessed via network management protocols data that is designed to be accessed via network management protocols
such as NETCONF <xref target="RFC6241"> </xref> or RESTCONF <xref such as NETCONF <xref target="RFC6241" format="default"> </xref> or REST
target="RFC8040"></xref>. These network management protocols are CONF <xref target="RFC8040" format="default"/>. These network management protoco
ls are
required to use a secure transport layer and mutual authentication, required to use a secure transport layer and mutual authentication,
e.g., SSH <xref target="RFC6242"></xref> without the "none" e.g., SSH <xref target="RFC6242" format="default"/> without the "none"
authentication option, Transport Layer Security (TLS) <xref authentication option, Transport Layer Security (TLS) <xref target="RFC8
target="RFC8446"></xref> with mutual X.509 authentication, and HTTPS 446" format="default"/> with mutual X.509 authentication, and HTTPS
with HTTP authentication (Section 11 of <xref with HTTP authentication (<xref target="RFC9110" sectionFormat="of" sect
target="RFC9110"></xref>).</t> ion="11"/>).</t>
<t>The Network Access Control Model (NACM) <xref target="RFC8341" format
<t>The Network Access Control Model (NACM) <xref ="default"/> provides the means to restrict access for
target="RFC8341"></xref> provides the means to restrict access for
particular users to a pre-configured subset of all available protocol particular users to a pre-configured subset of all available protocol
operations and content.</t> operations and content.</t>
<!-- DNE -->
<t>Please be aware that this YANG module uses groupings from other <t>Please be aware that this YANG module uses groupings from other
YANG modules that define nodes that may be considered sensitive or YANG modules that define nodes that may be considered sensitive or
vulnerable in network environments. Please review the Security vulnerable in network environments. Please review the Security
Considerations for dependent YANG modules for information as to which Considerations for dependent YANG modules for information as to which
nodes may be considered sensitive or vulnerable in network nodes may be considered sensitive or vulnerable in network
environments.</t> environments.</t>
<t>All the writable data nodes defined by this module may be <t>All the writable data nodes defined by this module may be
considered sensitive or vulnerable in some network environments. For considered sensitive or vulnerable in some network environments. For
instance, the addition or removal of references to trusted anchors, instance, the addition or removal of references to trusted anchors,
(D)TLS versions, cipher suites etc., can dramatically alter the (D)TLS versions, cipher suites, etc., can dramatically alter the
implemented security policy. For this reason, the NACM extension implemented security policy. For this reason, the NACM extension
"default-deny-write" has been set for all data nodes defined in this "default-deny-write" has been set for all data nodes defined in this
module.</t> module.</t>
<t>Some of the readable data nodes defined in this YANG module may be <t>Some of the readable data nodes defined in this YANG module may be
considered sensitive or vulnerable in some network environments. It is considered sensitive or vulnerable in some network environments. It is
thus important to control read access (e.g., via get, get-config, or thus important to control read access (e.g., via get, get-config, or
notification) to these data nodes. The YANG module will provide notification) to these data nodes. The YANG module will provide
insights into (D)TLS profiles of the IoT devices, the privacy insights into (D)TLS profiles of the IoT devices, and the privacy
considerations discussed in <xref target="Privacy"></xref> needs to be considerations discussed in <xref target="Privacy" format="default"/> ne
ed to be
taken into account.</t> taken into account.</t>
<t>This module does not define any RPCs, actions, or notifications, <t>This module does not define any RPCs, actions, or notifications,
and thus the security consideration for such is not provided here.</t> and thus the security consideration for such is not provided here.</t>
</section> </section>
<section numbered="true" toc="default">
<section title="Considerations for the &quot;ietf-mud-tls&quot; Module"> <name>Considerations for the "ietf-mud-tls" Module</name>
<t>This section follows the template defined in Section 3.7.1 of <xref <t>This section follows the template defined in <xref target="I-D.ietf-n
target="I-D.ietf-netmod-rfc8407bis"></xref>.</t> etmod-rfc8407bis" sectionFormat="of" section="3.7.1"/>.</t>
<!-- DNE -->
<t>The YANG module specified in this document defines a schema for <t>The "ietf-mud-tls" YANG module specified in this document defines a s
chema for
data can possibly be accessed via network management protocols such as data can possibly be accessed via network management protocols such as
NETCONF <xref target="RFC6241"></xref> or RESTCONF <xref NETCONF <xref target="RFC6241" format="default"/> or RESTCONF <xref targ
target="RFC8040"></xref>. These network management protocols are et="RFC8040" format="default"/>. These network management protocols are
required to use a secure transport layer and mutual authentication, required to use a secure transport layer and mutual authentication,
e.g., SSH <xref target="RFC6242"></xref> without the "none" e.g., SSH <xref target="RFC6242" format="default"/> without the "none"
authentication option, Transport Layer Security (TLS) <xref authentication option, Transport Layer Security (TLS) <xref target="RFC8
target="RFC8446"></xref> with mutual X.509 authentication, and HTTPS 446" format="default"/> with mutual X.509 authentication, and HTTPS
with HTTP authentication (Section 11 of <xref with HTTP authentication (<xref target="RFC9110" sectionFormat="of" sect
target="RFC9110"></xref>). Note that the YANG module is not intended ion="11"/>). Note that the YANG module is not intended
to be accessed via NETCONF and RESTCONF. This has already been to be accessed via NETCONF and RESTCONF. This has already been
discussed in <xref target="RFC8520"></xref>, and we are reiterating it discussed in <xref target="RFC8520" format="default"/>, and we are reite rating it
here for the sake of completeness.</t> here for the sake of completeness.</t>
<t>The Network Access Control Model (NACM) <xref target="RFC8341" format
<t>The Network Access Control Model (NACM) <xref ="default"/> provides the means to restrict access for
target="RFC8341"></xref> provides the means to restrict access for
particular users to a pre-configured subset of all available protocol particular users to a pre-configured subset of all available protocol
operations and content.</t> operations and content.</t>
<!-- DNE -->
<t>Please be aware that this YANG module uses groupings from other <t>Please be aware that this YANG module uses groupings from other
YANG modules that define nodes that may be considered sensitive or YANG modules that define nodes that may be considered sensitive or
vulnerable in network environments. Please review the Security vulnerable in network environments. Please review the Security
Considerations for dependent YANG modules for information as to which Considerations for dependent YANG modules for information as to which
nodes may be considered sensitive or vulnerable in network nodes may be considered sensitive or vulnerable in network
environments.</t> environments.</t>
<t>All the writable data nodes defined by this module may be <t>All the writable data nodes defined by this module may be
considered sensitive or vulnerable in some network environments. For considered sensitive or vulnerable in some network environments. For
instance, update that the device does not support (D)TLS profile can instance, update that the device does not support (D)TLS profile can
dramatically alter the implemented security policy. For this reason, dramatically alter the implemented security policy. For this reason,
the NACM extension "default-deny-write" has been set for all data the NACM extension "default-deny-write" has been set for all data
nodes defined in this module.</t> nodes defined in this module.</t>
<t>This module does not define any RPCs, actions, or notifications, <t>This module does not define any RPCs, actions, or notifications,
and thus the security consideration for such is not provided here.</t> and thus the security consideration for such is not provided here.</t>
</section> </section>
</section> </section>
<section anchor="Privacy" numbered="true" toc="default">
<section anchor="Privacy" title="Privacy Considerations"> <name>Privacy Considerations</name>
<t>Privacy considerations discussed in Section 16 of <xref <t>Privacy considerations discussed in <xref target="RFC8520" sectionForma
target="RFC8520"></xref> to not reveal the MUD URL to an attacker need t="of" section="16"/> to not reveal the MUD URL to an attacker need
to be taken into consideration. The MUD URL can be stored in Trusted to be taken into consideration. The MUD URL can be stored in a Trusted
Execution Environment (TEE) for secure operation, enhanced data Execution Environment (TEE) for secure operation, enhanced data
security, and prevent exposure to unauthorized software. The MUD URL security, and prevention of exposure to unauthorized software. The MUD URL
MUST be encrypted and shared only with the authorized components in the <bcp14>MUST</bcp14> be encrypted and shared only with the authorized compo
network (see Section 1.5 and Section 1.8 of [RFC8520]) so that an nents in the
network (see Sections <xref target="RFC8520" sectionFormat="bare" section=
"1.5"/> and <xref target="RFC8520" sectionFormat="bare" section="1.8"/> of <xref
target="RFC8520"/>) so that an
on-path attacker cannot read the MUD URL and identify the IoT device. on-path attacker cannot read the MUD URL and identify the IoT device.
Otherwise, it provides the attacker with guidance on what Otherwise, it provides the attacker with guidance on what
vulnerabilities may be present on the IoT device. Note that while vulnerabilities may be present on the IoT device. Note that while
protecting the MUD URL is valuable as described above, a compromised IoT protecting the MUD URL is valuable as described above, a compromised IoT
device may be susceptible to malware performing vulnerability analysis device may be susceptible to malware performing vulnerability analysis
(and version mapping) of the legitimate software located in memory or on (and version mapping) of the legitimate software located in memory or on
non-volatile storage (e.g., disk, NVRAM). However, the malware on the non-volatile storage (e.g., disk, NVRAM). However, the malware on the
IoT device is intended to be blocked from establishing a (D)TLS IoT device is intended to be blocked from establishing a (D)TLS
connection with the C&amp;C server to reveal this information because connection with the C&amp;C server to reveal this information because
the connection would be blocked by the network security service the connection would be blocked by the network security service
supporting this specification.</t> supporting this specification.</t>
<t>Full handshake inspection (<xref target="full" format="default"/>) requ
<t>Full handshake inspection (<xref target="full"></xref>) requires a ires a
(D)TLS proxy device which needs to decrypt traffic between the IoT (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 device and its server(s). There is a tradeoff between privacy of the
data carried inside (D)TLS (especially e.g., personally identifiable data carried inside (D)TLS (for example, personally identifiable
information and protected health information) and efficacy of endpoint information and protected health information especially) and efficacy of e
security. The use of (D)TLS proxies is NOT RECOMMENDED whenever ndpoint
security. The use of (D)TLS proxies is <bcp14>NOT RECOMMENDED</bcp14> when
ever
possible. For example, an enterprise firewall administrator can possible. For example, an enterprise firewall administrator can
configure the middlebox to bypass (D)TLS proxy functionality or payload configure the middlebox to bypass (D)TLS proxy functionality or payload
inspection for connections destined to specific well-known services. inspection for connections destined to specific well-known services.
Alternatively, a IoT device could be configured to reject all sessions Alternatively, an IoT device could be configured to reject all sessions
that involve proxy servers to specific well-known services. In addition, that involve proxy servers to specific well-known services. In addition,
mechanisms based on object security can be used by IoT devices to enable 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 end-to-end security and the middlebox will not have any access to the
packet data. For example, Object Security for Constrained RESTful packet data. For example, Object Security for Constrained RESTful
Environments (OSCORE) <xref target="RFC8613"></xref> is a proposal that Environments (OSCORE) <xref target="RFC8613" format="default"/> is a propo
protects CoAP messages by wrapping them in the COSE format <xref sal that
target="RFC9052"></xref>.</t> protects Constrained Application Protocol (CoAP) messages by wrapping them
in the CBOR Object Signing and Encryption (COSE) format <xref target="RFC9052"
format="default"/>.</t>
</section> </section>
<section anchor="IANA" numbered="true" toc="default">
<name>IANA Considerations</name>
<section numbered="true" toc="default">
<name>(D)TLS Profile YANG Modules</name>
<section anchor="IANA" title="IANA Considerations"> <t>IANA has registered the following URIs in the
<section title="(D)TLS Profile YANG Modules"> "ns" subregistry within the "IETF XML Registry" <xref target="RFC3688" f
<t>This document requests IANA to register the following URIs in the ormat="default"/>: </t>
"ns" subregistry within the "IETF XML Registry" <xref
target="RFC3688"></xref>: <figure>
<artwork><![CDATA[ URI: urn:ietf:params:xml:ns:yang:iana-tls-pr
ofile
Registrant Contact: IANA.
XML: N/A; the requested URI is an XML namespace.
]]></artwork>
</figure><figure>
<artwork><![CDATA[ URI: urn:ietf:params:xml:ns:yang:ietf-acl-tl
s
Registrant Contact: IESG.
XML: N/A; the requested URI is an XML namespace.
]]></artwork>
</figure><figure>
<artwork><![CDATA[ URI: urn:ietf:params:xml:ns:yang:ietf-mud-tl
s
Registrant Contact: IESG.
XML: N/A; the requested URI is an XML namespace.
]]></artwork>
</figure></t>
<t>IANA is requested to create an IANA-maintained YANG Module called <dl spacing="compact" newline="false">
"iana-tls-profile", based on the contents of <xref <dt>URI:</dt><dd>urn:ietf:params:xml:ns:yang:iana-tls-profile</dd>
target="yang-iana"></xref>, which will allow for new (D)TLS parameters <dt>Registrant Contact:</dt><dd>IANA.</dd>
and (D)TLS versions to be added to "client-profile".</t> <dt>XML:</dt><dd>N/A; the requested URI is an XML namespace.</dd>
</dl>
<dl spacing="compact" newline="false">
<dt>URI:</dt><dd>urn:ietf:params:xml:ns:yang:ietf-acl-tls</dd>
<dt>Registrant Contact:</dt><dd>IESG.</dd>
<dt>XML:</dt><dd>N/A; the requested URI is an XML namespace.</dd>
</dl>
<dl spacing="compact" newline="false">
<dt>URI:</dt><dd>urn:ietf:params:xml:ns:yang:ietf-mud-tls</dd>
<dt>Registrant Contact:</dt><dd>IESG.</dd>
<dt>XML:</dt><dd>N/A; the requested URI is an XML namespace.</dd>
</dl>
<t>This document requests IANA to register the following YANG modules <t>IANA has created an IANA-maintained YANG module called
in the "YANG Module Names" subregistry <xref target="RFC6020"></xref> "iana-tls-profile" based on the contents of <xref target="yang-iana" for
within the "YANG Parameters" registry.</t> mat="default"/>, which allows for new (D)TLS parameters
and (D)TLS versions to be added to "client-profile".</t>
<t>IANA has registered the following YANG modules
in the "YANG Module Names" registry <xref target="RFC6020" format="defau
lt"/>
of the "YANG Parameters" registry group.</t>
<t><figure> <dl spacing="compact" newline="false">
<artwork><![CDATA[ name: iana-tls-profile <dt>Name:</dt><dd>iana-tls-profile</dd>
namespace: urn:ietf:params:xml:ns:yang:iana-tls-profile <dt>Namespace:</dt><dd>urn:ietf:params:xml:ns:yang:iana-tls-profile</dd
maintained by IANA: Y >
prefix: ianatp <dt>Maintained by IANA:</dt><dd>Y</dd>
reference: RFC XXXX <dt>Prefix:</dt><dd>ianatp</dd>
]]></artwork> <dt>Reference:</dt><dd>RFC 9761</dd>
</figure><figure> </dl>
<artwork><![CDATA[ name: ietf-acl-tls <dl spacing="compact" newline="false">
namespace: urn:ietf:params:xml:ns:yang:ietf-acl-tls <dt>Name:</dt><dd>ietf-acl-tls</dd>
maintained by IANA: N <dt>Namespace:</dt><dd>urn:ietf:params:xml:ns:yang:ietf-acl-tls</dd>
prefix: ietf-acl-tls <dt>Maintained by IANA:</dt><dd>N</dd>
reference: RFC XXXX]]></artwork> <dt>Prefix:</dt><dd>ietf-acl-tls</dd>
</figure><figure> <dt>Reference:</dt><dd>RFC 9761</dd>
<artwork><![CDATA[ name: ietf-mud-tls </dl>
namespace: urn:ietf:params:xml:ns:yang:ietf-mud-tls <dl spacing="compact" newline="false">
maintained by IANA: N <dt>Name:</dt><dd>ietf-mud-tls</dd>
prefix: ietf-mud-tls <dt>Namespace:</dt><dd>urn:ietf:params:xml:ns:yang:ietf-mud-tls</dd>
reference: RFC XXXX]]></artwork> <dt>Maintained by IANA:</dt><dd>N</dd>
</figure></t> <dt>Prefix:</dt><dd>ietf-mud-tls</dd>
<dt>Reference:</dt><dd>RFC 9761</dd>
</dl>
</section> </section>
<section anchor="iana-tls" numbered="true" toc="default">
<section anchor="iana-tls" <name>Considerations for the iana-tls-profile Module</name>
title="Considerations for the iana-tls-profile Module"> <t>IANA has created the initial version of the
<t>IANA is requested to create the initial version of the IANA-maintained YANG module called "iana-tls-profile" based on the
IANA-maintained YANG Module called "iana-tls-profile", based on the contents of <xref target="yang-iana" format="default"/>, which will allo
contents of <xref target="yang-iana"></xref>, which will allow for new w for new
(D)TLS parameters and (D)TLS versions to be added. IANA is requested (D)TLS parameters and (D)TLS versions to be added. IANA is requested
to add this note:</t> to add this note:</t>
<ul spacing="normal">
<t><list style="symbols"> <li>
<t>tls-version and dtls-version values must not be directly added <t>tls-version and dtls-version values must not be directly added
to the iana-tls-profile YANG module. They must instead be to the iana-tls-profile YANG module. Instead, they must be
respectively added to the "ACL TLS Version Codes", and "ACL DTLS added to the "ACL TLS Version Codes" and "ACL DTLS
Version Codes" registries provided the new (D)TLS version has been Version Codes" registries (respectively), provided the new (D)TLS ve
standardized by the IETF. It allows new (D)TLS version to be added rsion has been
to the "iana-tls-profile" YANG Module.</t> standardized by the IETF. It allows a new (D)TLS version to be added
to the "iana-tls-profile" YANG module.</t>
</li>
<li>
<t>(D)TLS parameters must not be directly added to the <t>(D)TLS parameters must not be directly added to the
iana-tls-profile YANG module. They must instead be 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 "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 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 behavior. It allows new (D)TLS parameters to be added to the
"iana-tls-profile" YANG Module,</t> "iana-tls-profile" YANG module.</t>
</list></t> </li>
</ul>
<t>When a 'tls-version' or 'dtls-version' value is respectively added <t>When a "tls-version" or "dtls-version" value is added
to the "ACL TLS Version Codes" or "ACL DTLS Version Codes" registry, a to the "ACL TLS Version Codes" or "ACL DTLS Version Codes" registry (res
pectively), a
new "enum" statement must be added to the iana-tls-profile YANG new "enum" statement must be added to the iana-tls-profile YANG
module. The following "enum" statement, and substatements thereof, module. The following "enum" statement, and substatements thereof,
should be defined:<list hangIndent="15" style="hanging"> should be defined:</t>
<t hangText="&quot;enum&quot;:">Replicates the label from the <dl newline="false" spacing="normal" indent="15">
registry.</t> <dt>"enum":</dt>
<dd>Replicates the label from the
<t hangText="&quot;value&quot;:">Contains the IANA-assigned value registry.</dd>
corresponding to the 'tls-version' or 'dtls-version'.</t> <dt>"value":</dt>
<dd>Contains the IANA-assigned value
<t hangText="&quot;description&quot;:">Replicates the description corresponding to the "tls-version" or "dtls-version".</dd>
from the registry.</t> <dt>"description":</dt>
<dd>Replicates the description
<t hangText="&quot;reference&quot;:">RFC YYYY: &lt;Title of the from the registry.</dd>
RFC &gt;, where YYYY is the RFC that added the <dt>"reference":</dt>
&rsquo;tls-version&rsquo; or &lsquo;dtls-version&rsquo;</t> <dd>RFC YYYY: &lt;Title of the
</list></t> RFC&gt;, where YYYY is the RFC that added the
"tls-version" or "dtls-version"</dd>
<t>When a (D)TLS parameter is added to "ACL (D)TLS Parameters" </dl>
<t>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 registry, a new "type" statement must be added to the iana-tls-profile
YANG module. The following "type" statement, and substatements YANG module. The following "type" statement, and substatements
thereof, should be defined:<list hangIndent="15" style="hanging"> thereof, should be defined:</t>
<t hangText="&quot;derived type&quot;:">Replicates the parameter <dl newline="false" spacing="normal" indent="15">
name from the registry.</t> <dt>"derived type":</dt>
<dd>Replicates the parameter
<t hangText="&quot;built-in type&quot;:">Contains the built-in name from the registry.</dd>
YANG type.</t> <dt>"built-in type":</dt>
<dd>Contains the built-in
<t hangText="&quot;description&quot;:">Replicates the description YANG type.</dd>
from the registry.</t> <dt>"description":</dt>
</list></t> <dd>Replicates the description
from the registry.</dd>
</dl>
<t>When the iana-tls-profile YANG module is updated, a new "revision" <t>When the iana-tls-profile YANG module is updated, a new "revision"
statement must be added in front of the existing revision statement must be added in front of the existing revision
statements.</t> statements.</t>
<t>IANA has added this note to "ACL TLS Version Codes", "ACL
<t>IANA is requested to add this note to "ACL TLS Version Codes", "ACL
DTLS Version Codes", and "ACL (D)TLS Parameters" registries:</t> DTLS Version Codes", and "ACL (D)TLS Parameters" registries:</t>
<t><list style="empty"> <t indent="3">When this registry is modified, the YANG module
<t>When this registry is modified, the YANG module "iana-tls-profile" must be updated as defined in [RFC9761].</t>
iana-tls-profile must be updated as defined in [RFCXXXX].</t>
</list></t>
</section>
<section anchor="tls-registry" title="ACL TLS Version registry"> </section>
<t>IANA is requested to create a new registry titled "ACL TLS Version <section anchor="tls-registry" numbered="true" toc="default">
<name>ACL TLS Version Registry</name>
<t>IANA has created a new registry titled "ACL TLS Version
Codes". Codes in this registry are used as valid values of Codes". Codes in this registry are used as valid values of
'tls-version' parameter. Further assignments are to be made through "tls-version" parameter. Further assignments are to be made through
Expert Review <xref target="RFC8126"></xref>. Experts must ensure that Expert Review <xref target="RFC8126" format="default"/>. Experts must en
sure that
the TLS protocol version in a new registration is one that has been 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 standardized by the IETF. It is expected that the registry will be
updated infrequently, primarily when a new TLS version is standardized updated infrequently, primarily when a new TLS version is standardized
by the IETF.</t> by the IETF.</t>
<t><figure> <table>
<artwork><![CDATA[ +-------+---------+-----------------+---------- <name></name>
-+ <thead>
| Value | Label | Description | Reference | <tr>
| | | | | <th>Value</th>
| | | | | <th>Label</th>
+-------+---------+-----------------+-----------+ <th>Description</th>
| 1 | tls12 | TLS Version 1.2 | [RFC5246] | <th>Reference</th>
+-------+---------+-----------------+-----------+ </tr>
| 2 | tls13 | TLS Version 1.3 | [RFC8446] | </thead>
+-------+---------+-----------------+-----------+ <tbody>
]]></artwork> <tr>
</figure></t> <td>1</td>
</section> <td>tls12</td>
<td>TLS Version 1.2</td>
<td><xref target="RFC5246"/></td>
</tr>
<tr>
<td>2</td>
<td>tls13</td>
<td>TLS Version 1.3</td>
<td><xref target="RFC8446"/></td>
</tr>
</tbody>
</table>
<section anchor="dtls-registry" title="ACL DTLS version registry"> </section>
<t>IANA is requested to create a new registry titled "ACL DTLS Version <section anchor="dtls-registry" numbered="true" toc="default">
<name>ACL DTLS Version Registry</name>
<t>IANA has created a new registry titled "ACL DTLS Version
Codes". Codes in this registry are used as valid values of Codes". Codes in this registry are used as valid values of
'dtls-version' parameter. Further assignments are to be made through "dtls-version" parameter. Further assignments are to be made through
Expert Review <xref target="RFC8126"></xref>. Experts must ensure that Expert Review <xref target="RFC8126" format="default"/>. Experts must en
sure that
the DTLS protocol version in a new registration is one that has been 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 standardized by the IETF. It is expected that the registry will be
updated infrequently, primarily when a new DTLS version is updated infrequently, primarily when a new DTLS version is
standardized by the IETF.</t> standardized by the IETF.</t>
<t><figure> <table>
<artwork><![CDATA[ <name></name>
+-------+---------+----------------+-----------------------+ <thead>
| Value | Label | Description | Reference | <tr>
| | | | | <th>Value</th>
| | | | | <th>Label</th>
+-------+---------+----------------+-----------------------+ <th>Description</th>
| 1 |dtls12 |DTLS Version 1.2| [RFC6347] | <th>Reference</th>
+-------+---------+----------------+-----------------------+ </tr>
| 2 |dtls13 |DTLS Version 1.3| [RFC9147| | </thead>
+-------+---------+----------------+-----------------------+ <tbody>
<tr>
<td>1</td>
<td>dtls12</td>
<td>DTLS Version 1.2</td>
<td><xref target="RFC6347"/></td>
</tr>
<tr>
<td>2</td>
<td>dtls13</td>
<td>DTLS Version 1.3</td>
<td><xref target="RFC9147"/></td>
</tr>
</tbody>
</table>
]]></artwork>
</figure></t>
</section> </section>
<section numbered="true" toc="default">
<section title="ACL (D)TLS Parameters registry"> <name>ACL (D)TLS Parameters Registry</name>
<t>IANA is requested to create a new registry titled "ACL (D)TLS <t>IANA has created a new registry titled "ACL (D)TLS
parameters".</t> parameters".</t>
<t>The values for all the (D)TLS parameters in the registry are <t>The values for all the (D)TLS parameters in the registry are
defined in the TLS and DTLS IANA registries (<eref defined in the TLS and DTLS IANA registries (<eref target="https://www.i
target="https://www.iana.org/assignments/tls-parameters/tls-parameters.t ana.org/assignments/tls-parameters/"/>
xt"></eref> and <eref target="https://www.iana.org/assignments/tls-extensiontype-val
and <eref ues/"/>)
target="https://www.iana.org/assignments/tls-extensiontype-values/tls-ex
tensiontype-values.txt"></eref>)
excluding the tls-version and dtls-version parameters. Further excluding the tls-version and dtls-version parameters. Further
assignments are to be made through Expert Review <xref assignments are to be made through Expert Review <xref target="RFC8126"
target="RFC8126"></xref>. Experts must ensure that the (D)TLS format="default"/>. Experts must ensure that the (D)TLS
parameter in a new registration is one that has been standardized by parameter in a new registration is one that has been standardized by
the IETF. The registry is expected to be updated periodically, the IETF. The registry is expected to be updated periodically,
primarily when a new (D)TLS parameter is standardized by the IETF. The primarily when a new (D)TLS parameter is standardized by the IETF. The
registry is initially populated with the following parameters:</t> registry has been populated with the following initial parameters:</t>
<t><figure> <table>
<artwork><![CDATA[ +----------------------------+-------------+--- <name></name>
-----+---------------------------------------------+ <thead>
| Parameter Name | YANG | JSON | <tr>
| <th>Parameter Name</th>
| | Type | Type | Description <th>YANG Type</th>
| <th>JSON Type</th>
| | | | <th>Description</th>
| </tr>
+----------------------------+-------------+--------+------------------------ </thead>
---------------------+ <tbody>
| extension-type | uint16 | Number | Extension type <tr>
| <td>extension-type</td>
+----------------------------+-------------+--------+------------------------ <td>uint16</td>
---------------------+ <td>Number</td>
| supported-group | uint16 | Number | Supported group <td>Extension type</td>
| </tr>
+----------------------------+-------------+--------+------------------------ <tr>
---------------------+ <td>supported-group</td>
| signature-algorithm | uint16 | Number | Signature algorithm <td>uint16</td>
| <td>Number</td>
+----------------------------+-------------+--------+------------------------ <td>Supported group</td>
---------------------+ </tr>
| psk-key-exchange-mode | uint8 | Number | pre-shared key exchange <tr>
mode | <td>signature-algorithm</td>
+----------------------------+-------------+--------+------------------------ <td>uint16</td>
---------------------+ <td>Number</td>
| application-protocol | string | String | Application protocol <td>Signature algorithm</td>
| </tr>
+----------------------------+-------------+--------+------------------------ <tr>
---------------------+ <td>psk-key-exchange-mode</td>
| cert-compression-algorithm | uint16 | Number | Certificate compression <td>uint8</td>
algorithm | <td>Number</td>
+----------------------------+-------------+--------+------------------------ <!--[rfced] Table 3: For psk-key-exchange-mode, would you like the
---------------------+ description to start with a capital letter, to be consistent with the
| cipher-algorithm | uint16 | Number | Cipher Suite other descriptions? If so, we will ask IANA to update the registry
| (https://www.iana.org/assignments/acl-tls) accordingly.
+----------------------------+-------------+--------+------------------------
---------------------+
| tls-version | enumeration | String | TLS version
|
+----------------------------+-------------+--------+------------------------
---------------------+
| dtls-version | enumeration | String | DTLS version
|
+----------------------------+-------------+--------+------------------------
---------------------+
]]></artwork> Current: pre-shared key exchange mode
</figure></t>
</section> Perhaps: Pre-shared key exchange mode
-->
<td>pre-shared key exchange mode</td>
</tr>
<tr>
<td>application-protocol</td>
<td>string</td>
<td>String</td>
<td>Application protocol</td>
</tr>
<tr>
<td>cert-compression-algorithm</td>
<td>uint16</td>
<td>Number</td>
<td>Certificate compression algorithm</td>
</tr>
<tr>
<td>cipher-algorithm</td>
<td>uint16</td>
<td>Number</td>
<td>Cipher Suite</td>
</tr>
<tr>
<td>tls-version</td>
<td>enumeration</td>
<td>String</td>
<td>TLS version</td>
</tr>
<tr>
<td>dtls-version</td>
<td>enumeration</td>
<td>String</td>
<td>DTLS version</td>
</tr>
</tbody>
</table>
<section title="MUD Extensions registry">
<t>IANA is requested to create a new MUD Extension Name "ietf-mud-tls"
in the MUD Extensions IANA registry <eref
target="https://www.iana.org/assignments/mud/mud.xhtml"></eref>.</t>
</section> </section>
</section> <section numbered="true" toc="default">
<name>MUD Extensions Registry</name>
<!-- Note to PE/RE: XML for references to the IANA registries mentionend
in this section.
<section anchor="acknowledgments" title="Acknowledgments"> "MUD Extensions" registry in the "Manufacturer Usage Description (MUD)" registry
<t>Thanks to Flemming Andreasen, Shashank Jain, Michael Richardson, group
Piyush Joshi, Eliot Lear, Harsha Joshi, Qin Wu, Mohamed Boucadair, Ben
Schwartz, Eric Rescorla, Panwei William, Nick Lamb, Tom Petch, Paul
Wouters, Thomas Fossati and Nick Harper for the discussion and
comments.</t>
<t>Thanks to Xufeng Liu for YANGDOCTOR review. Thanks to Linda Dunbar <reference anchor="" target="https://www.iana.org/assignments/mud">
for SECDIR review. Thanks to Qin Wu for OPSDIR review. Thanks to R. <front>
Gieben for DNSDIR review.</t> <title>MUD Extensions</title>
<author>
<organization>IANA</organization>
</author>
</front>
</reference>
<t>Thanks to Roman Danyliw, Orie Steele, &Eacute;ric Vyncke, Mahesh -->
Jethanandani, Murray Kucherawy, Zaheduzzaman Sarker and Deb Cooley for <t>IANA has created a new MUD Extension Name "ietf-mud-tls"
the IESG review.</t> in the "MUD Extensions" IANA registry <eref target="https://www.iana.org
/assignments/mud" brackets="angle"/>.</t>
</section>
</section> </section>
</middle> </middle>
<back> <back>
<references title="Normative References"> <displayreference target="I-D.ietf-tls-esni" to="TLS-ESNI"/>
<?rfc include="reference.RFC.2119"?> <displayreference target="I-D.ietf-uta-tls13-iot-profile" to="IoT-PROFILE"/>
<displayreference target="I-D.ietf-netmod-rfc8407bis" to="YANG-GUIDELINES"/>
<?rfc include='reference.RFC.8174'?> <references>
<name>References</name>
<?rfc include="reference.RFC.8446"?> <references>
<name>Normative References</name>
<?rfc include="reference.RFC.8519"?> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2
119.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
174.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
446.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
519.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3
688.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
701.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5
246.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6
347.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9
147.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
520.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.96
40.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
879.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6
241.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
040.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6
242.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9
110.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
341.xml"/>
<?rfc include='reference.RFC.3688'?> <!-- [rfced] Please review the questions below regarding references in this
document.
<?rfc include='reference.RFC.8701'?> a) Re: [X690], we added the URL
https://www.itu.int/rec/T-REC-X.690-200207-S/en. However, it has been
superseded by this version that was released in February 2021:
https://www.itu.int/rec/T-REC-X.690-202102-I/en. May we update this reference
to use the most current version?
<?rfc include='reference.RFC.5246'?> Current:
[X690] ITU-T, "Information technology - ASN.1 encoding Rules:
Specification of Basic Encoding Rules (BER), Canonical
Encoding Rules (CER) and Distinguished Encoding Rules
(DER)", ITU-T Recommendation X.690, July 2002,
<https://www.itu.int/rec/T-REC-X.690-200207-S/en>.
<?rfc include='reference.RFC.6347'?> b) We note that there are no citations for [RFC8484] in this document. Please
let us know if there is a specific place in the document where we can cite
this RFC. Otherwise, we will remove this from the Informative References.
<?rfc include='reference.RFC.9147'?> c) Re: [X501], this reference has been superseded
by the 2019 version of X.501 - available here:
https://www.itu.int/rec/T-REC-X.501-201910-I/en. May we update this reference
to use the most current version? FYI, the URL for the
1993 version of this reference has been included in the reference.
<?rfc include='reference.RFC.8520'?> Current:
[X501] "Information Technology - Open Systems Interconnection -
The Directory: Models", ITU-T Recommendation X.501,
November 1993,
<https://www.itu.int/rec/T-REC-X.501-199311-S/en>.
<?rfc include="reference.I-D.ietf-netconf-crypto-types" ?> d) Re: [CRYPTO-VULNERABILITY], the information provided does not
match the information provided at the URL (which directs to an NSA
Cybersecurity Advisory with the title "Patch Critical Cryptographic Vulnerabilit
y in Microsoft Windows Clients and Servers" with a date of 14 January 2020).
<?rfc include='reference.RFC.8879'?> Upon further research, we found the following URL:
https://securityboulevard.com/2020/01/exploiting-the-windows-cryptoapi-vulnerabi
lity/. The
title, date, and author at this URL match the original reference information
provided. Is that the correct URL for this reference? Or should we update
this reference to match the information provided at the original URL,
i.e., the NSA Cybersecurity Advisory?
<?rfc include='reference.RFC.6241'?> Original:
[cryto-vulnerability]
Perez, B., "Exploiting the Windows CryptoAPI
Vulnerability", January 2020,
<https://media.defense.gov/2020/Jan/14/2002234275/-1/-1/0/
CSA-WINDOWS-10-CRYPT-LIB-20190114.PDF>.
<?rfc include='reference.RFC.8040'?> e) FYI, we removed mention of "Cisco" from this reference,
as there is no mention of "Cisco" at this archived URL.
Please let us know if other changes are needed.
<?rfc include='reference.RFC.6242'?> Original:
[slowloris]
Cisco, "Slowloris HTTP DoS",
<https://web.archive.org/web/20150315054838/
http://ha.ckers.org/slowloris/>.
<?rfc include='reference.RFC.9110'?> Current:
[SLOWLORIS]
"Slowloris HTTP DoS", Wayback Machine archive,
<https://web.archive.org/web/20150315054838/
http://ha.ckers.org/slowloris/>.
-->
<?rfc include='reference.RFC.8341'?> <!--
<reference anchor="X690" target="https://www.itu.int/rec/T-REC-X.690-202102-I/en
">
<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>ITU-T</organization>
</author>
<date year="2021"/>
</front>
<seriesInfo name="ITU-T Recommendation" value="X.690"/>
</reference> -->
<reference anchor="X690"> <reference anchor="X690" target="https://www.itu.int/rec/T-REC-X.690-200
<front> 207-S/en">
<title>Information technology - ASN.1 encoding Rules: Specification <front>
<title>Information technology - ASN.1 encoding Rules: Specification
of Basic Encoding Rules (BER), Canonical Encoding Rules (CER) and of Basic Encoding Rules (BER), Canonical Encoding Rules (CER) and
Distinguished Encoding Rules (DER)</title> Distinguished Encoding Rules (DER)</title>
<author>
<organization>ITU-T</organization>
</author>
<date month="July" year="2002"/>
</front>
<seriesInfo name="ITU-T Recommendation" value="X.690"/>
</reference>
<author> </references>
<organization>ITU-T</organization> <references>
</author> <name>Informative References</name>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7
<date year="2002" /> 951.xml"/>
</front> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
576.xml"/>
<seriesInfo name="ISO/IEC" value="8825-1:2002" />
</reference>
</references>
<references title="Informative References">
<?rfc include='reference.RFC.7951'?>
<?rfc include="reference.RFC.8576"?>
<?rfc include="reference.RFC.8484"?>
<?rfc include="reference.RFC.6020"?>
<?rfc include='reference.RFC.8126'?>
<?rfc include='reference.RFC.7925'?>
<?rfc include='reference.RFC.7366'?>
<?rfc include='reference.RFC.6066'?>
<?rfc include='reference.RFC.8472'?>
<?rfc include='reference.RFC.9325'?>
<?rfc include='reference.RFC.7301'?>
<?rfc include="reference.RFC.9052"?>
<?rfc include='reference.RFC.8613'?>
<?rfc include='reference.RFC.8447'?> <!-- <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.R FC.8484.xml"/> -->
<?rfc include='reference.RFC.8340'?> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6
020.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
126.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7
925.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7
366.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6
066.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
472.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9
325.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7
301.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9
052.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
613.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
447.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
340.xml"/>
<?rfc include="reference.I-D.ietf-tls-esni" ?> <!-- [I-D.ietf-tls-esni] IESG state: I-D Exists as of 09/05/24 -->
<xi:include href="https://datatracker.ietf.org/doc/bibxml3/reference.I-D
.ietf-tls-esni.xml"/>
<?rfc include='reference.RFC.9462'?> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9
462.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9
463.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7
858.xml"/>
<?rfc include='reference.RFC.9463'?> <!-- [I-D.ietf-uta-tls13-iot-profile] IESG state: Expired as of 09/05/24 -->
<xi:include href="https://datatracker.ietf.org/doc/bibxml3/reference.I-D
.ietf-uta-tls13-iot-profile.xml"/>
<?rfc include='reference.RFC.7858'?> <!-- [I-D.ietf-netmod-rfc8407bis] IESG state: I-D Exists as of 09/05/24 -->
<xi:include href="https://datatracker.ietf.org/doc/bibxml3/reference.I-D
.ietf-netmod-rfc8407bis.xml"/>
<?rfc include="reference.I-D.ietf-uta-tls13-iot-profile" ?> <!-- Note to PE:
<?rfc include="reference.I-D.ietf-netmod-rfc8407bis"?> XML for 2019 version of [X501]:
<reference anchor="X501"> <reference anchor="X501" target="https://www.itu.int/rec/T-REC-X.501-201
<front> 910-I/en">
<title>Information Technology - Open Systems Interconnection - The <front>
<title>Information Technology - Open Systems Interconnection - The
Directory: Models</title> Directory: Models</title>
<author>
<organization/>
</author>
<date month="October" year="2019"/>
</front>
<seriesInfo name="ITU-T Recommendation" value="X.501"/>
</reference>
<author> -->
<organization></organization> <reference anchor="X501" target="https://www.itu.int/rec/T-REC-X.501-199
</author> 311-S/en">
<front>
<date year="1993" /> <title>Information Technology - Open Systems Interconnection - The
</front> Directory: Models</title>
<author>
<seriesInfo name="ITU-T" value="X.501" /> <organization/>
</reference> </author>
<date month="November" year="1993"/>
<reference anchor="clear-as-mud" </front>
target="https://arxiv.org/pdf/1804.04358.pdf"> <seriesInfo name="ITU-T Recommendation" value="X.501"/>
<front> </reference>
<title>Clear as MUD: Generating, Validating and Applying IoT
Behaviorial Profiles</title>
<author>
<organization></organization>
</author>
<date month="October" year="2019" /> <reference anchor="CLEAR-AS-MUD" target="https://arxiv.org/pdf/1804.0435
</front> 8.pdf">
</reference> <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="malware-tls" <reference anchor="MALWARE-TLS" target="https://dl.acm.org/citation.cfm?
target="https://dl.acm.org/citation.cfm?id=3355601"> id=3355601">
<front> <front>
<title>TLS Beyond the Browser: Combining End Host and Network Data <title>TLS Beyond the Browser: Combining End Host and Network Data
to Understand Application Behavior</title> to Understand Application Behavior</title>
<author fullname="Blake Anderson" initials="B." surname="Anderson">
<organization>Cisco</organization>
</author>
<author fullname="David McGrew" initials="D." surname="McGrew">
<organization>Cisco</organization>
</author>
<date month="October" year="2019"/>
</front>
<refcontent>IMC '19: Proceedings of the Internet Measurement Conferenc
e, pp. 379-392</refcontent>
<seriesInfo name="DOI" value="10.1145/3355369.3355601"/>
</reference>
<author fullname="Blake Anderson" initials="B." surname="Anderson"> <!-- Note to PE: XML for the NSA Cybersecurity Advisory (if the authors wish to
<organization>Cisco</organization> use that source)
</author> <reference anchor="cryto-vulnerability" target="https://media.defense.go
v/2020/Jan/14/2002234275/-1/-1/0/CSA-WINDOWS-10-CRYPT-LIB-20190114.PDF">
<author fullname="David McGrew" initials="D." surname="McGrew"> <front>
<organization>Cisco</organization> <title>Patch Critical Cryptographic Vulnerability in Microsoft Windo
</author> ws Clients and Servers</title>
<author>
<date month="October" year="2019" /> <organization>National Security Agency</organization>
</front> </author>
</reference> <date month="January" year="2020"/>
</front>
<reference anchor="cryto-vulnerability" <refcontent>National Security Agenct Cybersecurity Advisory</refconten
target="https://media.defense.gov/2020/Jan/14/2002234275/-1/-1/ t>
0/CSA-WINDOWS-10-CRYPT-LIB-20190114.PDF"> </reference>
<front>
<title>Exploiting the Windows CryptoAPI Vulnerability</title>
<author fullname="Ben Perez" initials="B." surname="Perez"> -->
<organization>Cisco</organization>
</author>
<date month="January" year="2020" /> <reference anchor="CRYPTO-VULNERABILITY" target="https://media.defense.g
</front> ov/2020/Jan/14/2002234275/-1/-1/0/CSA-WINDOWS-10-CRYPT-LIB-20190114.PDF">
</reference> <front>
<title>Exploiting the Windows CryptoAPI Vulnerability</title>
<author fullname="Ben Perez" initials="B." surname="Perez">
<organization>Cisco</organization>
</author>
<date month="January" year="2020"/>
</front>
</reference>
<reference anchor="malware-doh" <reference anchor="MALWARE-DOH" target="https://www.zdnet.com/article/fi
target="https://www.zdnet.com/article/first-ever-malware-strain rst-ever-malware-strain-spotted-abusing-new-doh-dns-over-https-protocol/">
-spotted-abusing-new-doh-dns-over-https-protocol/"> <front>
<front> <title>First-ever malware strain spotted abusing new DoH (DNS over
<title>First-ever malware strain spotted abusing new DoH (DNS over
HTTPS) protocol</title> HTTPS) protocol</title>
<author fullname="Catalin Cimpanu" initials="C." surname="Cimpanu">
</author>
<date month="July" year="2019"/>
</front>
<refcontent>ZDNET</refcontent>
</reference>
<author fullname="Catalin Cimpanu" initials="C." surname="Cimpanu"> <reference anchor="SLOWLORIS" target="https://web.archive.org/web/201503
<organization>Cisco</organization> 15054838/http://ha.ckers.org/slowloris/">
</author> <front>
<title>Slowloris HTTP DoS</title>
<date month="July" year="2019" /> <author><organization>ha.ckers.org security lab</organization></auth
</front> or>
</reference> <date month="March" year="2015"/>
</front>
<reference anchor="slowloris" <refcontent>Wayback Machine archive</refcontent>
target="https://web.archive.org/web/20150315054838/http://ha.ck </reference>
ers.org/slowloris/">
<front>
<title>Slowloris HTTP DoS</title>
<author fullname="" initials="" surname=""> <reference anchor="EVE" target="https://secure.cisco.com/secure-firewall
<organization>Cisco</organization> /docs/encrypted-visibility-engine">
</author> <front>
<title>Encrypted Visibility Engine</title>
<author fullname="" initials="" surname="">
<organization>Cisco</organization>
</author>
<date month="" year=""/>
</front>
<refcontent>Cisco Secure Firewall documentation</refcontent>
</reference>
<date month="" year="" /> </references>
</front> </references>
</reference> <!-- [rfced] Please review the following terms and let us know how we should
update. If there are no objections, we will use the form on the right for
consistency.
<reference anchor="eve" Cipher Suite vs. cipher suite
target="https://secure.cisco.com/secure-firewall/docs/encrypted [1 instance of "Cipher suite" at the start of a description
-visibility-engine"> will remain as is.]
<front>
<title>Encrypted Visibility Engine</title>
<author fullname="" initials="" surname=""> certificate message (1 instance) vs. Certificate message
<organization>Cisco</organization> There is one instance of "certificate message" (lowercase 'c') in
</author> "server certificate message" in Section 1. Should it be changed to
"Certificate message"? Elsewhere it seems this document is using
the term as defined in RFC 8446.
-->
<section anchor="acknowledgments" numbered="false" toc="default">
<name>Acknowledgments</name> <t>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>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. Giebe
n"/> for DNSDIR review.</t> <t>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>
<date month="" year="" /> </back> </rfc>
</front>
</reference>
</references>
</back>
</rfc>
 End of changes. 304 change blocks. 
929 lines changed or deleted 1388 lines changed or added

This html diff was produced by rfcdiff 1.48.