rfc9761v1.txt		rfc9761.txt
	Internet Engineering Task Force (IETF) T. Reddy.K		Internet Engineering Task Force (IETF) T. Reddy.K
	Request for Comments: 9761 Nokia		Request for Comments: 9761 Nokia
	Category: Standards Track D. Wing		Category: Standards Track D. Wing
	ISSN: 2070-1721 Citrix		ISSN: 2070-1721 Citrix
	B. Anderson		B. Anderson
	Cisco		Cisco
	March 2025		April 2025
	Manufacturer Usage Description (MUD) for TLS and DTLS Profiles for		Manufacturer Usage Description (MUD) for TLS and DTLS Profiles for
	Internet of Things (IoT) Devices		Internet of Things (IoT) Devices
	Abstract		Abstract
	This memo extends the Manufacturer Usage Description (MUD)		This memo extends the Manufacturer Usage Description (MUD)
	specification to allow manufacturers to define TLS and DTLS 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		unexpected (D)TLS usage, which can indicate the presence of
	skipping to change at line 116 ¶		skipping to change at line 116 ¶
	* TLS server name indication (SNI) extension [RFC6066] and server		* TLS server name indication (SNI) extension [RFC6066] and server
	certificates are composed of subjects with characteristics of a		certificates are composed of subjects with characteristics of a
	domain generation algorithm (DGA) (e.g., "www.33mhwt2j.net").		domain generation algorithm (DGA) (e.g., "www.33mhwt2j.net").
	* Higher use of self-signed certificates compared with typical		* Higher use of self-signed certificates compared with typical
	legitimate software using certificates from a certificate		legitimate software using certificates from a certificate
	authority (CA) trusted by the device.		authority (CA) trusted by the device.
	* Discrepancies in the SNI TLS extension and the DNS names in the		* 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.		message.
	* Discrepancies in the key exchange algorithm and the client public		* Discrepancies in the key exchange algorithm and the client public
	key length in comparison with legitimate flows. As a reminder,		key length in comparison with legitimate flows. As a reminder,
	the Client Key Exchange message has been removed from TLS 1.3.		the Client Key Exchange message has been removed from TLS 1.3.
	* Lower diversity in extensions advertised by TLS clients compared		* Lower diversity in extensions advertised by TLS clients compared
	to legitimate clients.		to legitimate clients.
	* Using privacy enhancing technologies like Tor, Psiphon, Ultrasurf		* Using privacy enhancing technologies like Tor, Psiphon, Ultrasurf
	(see [MALWARE-TLS]), and evasion techniques such as ClientHello		(see [MALWARE-TLS]), and evasion techniques such as ClientHello
	randomization.		randomization.
	* Using an alternative DNS server (via encrypted transport) to avoid		* Using an alternative DNS server (via encrypted transport) to avoid
	detection by malware DNS filtering services [MALWARE-DOH].		detection by malware DNS filtering services [MALWARE-DOH].
	Specifically, malware may not use the Do53 or encrypted DNS server		Specifically, malware may not use the Do53 or encrypted DNS server
	provided by the local network (DHCP, Discovery of Network-		provided by the local network (DHCP, Discovery of Network-
	designated Resolvers (DNR) [RFC9462], or Discovery of Designated		designated Resolvers (DNR) [RFC9463], or Discovery of Designated
	Resolvers (DDR) [RFC9462]).		Resolvers (DDR) [RFC9462]).
	If (D)TLS profile parameters are defined, the following functions		If (D)TLS profile parameters are defined, the following functions
	that have a positive impact on the local network security are		that have a positive impact on the local network security are
	possible:		possible:
	* Permit intended DTLS or TLS use, and block malicious DTLS or TLS		* Permit intended DTLS or TLS use, and block malicious DTLS or TLS
	use. This is superior to the layers 3 and 4 Access Control Lists		use. This is superior to the Access Control Lists (ACLs) of
	(ACLs) of Manufacturer Usage Description Specification (MUD)		Layers 3 and 4 in "Manufacturer Usage Description Specification"
	[RFC8520], which are not suitable for broad communication		[RFC8520], which are not suitable for broad communication
	patterns. The goal of this document is to enhance and complement		patterns. The goal of this document is to enhance and complement
	the existing MUD specifications rather than undermine them.		the existing MUD specifications rather than undermine them.
	* Ensure TLS certificates are valid. Several TLS deployments have		* 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 [CRYPTO-VULNERABILITY]). By		certificate validation function (see [CRYPTO-VULNERABILITY]). By
	observing (D)TLS profile parameters, a network element can detect		observing (D)TLS profile parameters, a network element can detect
	when the TLS SNI mismatches the SubjectAltName and when the		when the TLS SNI mismatches the SubjectAltName and when the
	skipping to change at line 209 ¶		skipping to change at line 209 ¶
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and		"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
	"OPTIONAL" in this document are to be interpreted as described in		"OPTIONAL" in this document are to be interpreted as described in
	BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all		BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
	capitals, as shown here.		capitals, as shown here.
	(D)TLS: Used for statements that apply to both Transport Layer		(D)TLS: Used for statements that apply to both Transport Layer
	Security [RFC8446] and Datagram Transport Layer Security		Security [RFC8446] and Datagram Transport Layer Security
	[RFC6347]. Specific terms "TLS" and "DTLS" are used for any		[RFC6347]. Specific terms "TLS" and "DTLS" are used for any
	statement that applies to either protocol alone.		statement that applies to either protocol alone.
	DoH/DoT: Refers to DNS-over-HTTPS and/or DNS-over-TLS [RFC7858].		DoH/DoT: Refers to DNS-over-HTTPS [RFC8484] and/or DNS-over-TLS
			[RFC7858].
	Middlebox: A middlebox that interacts with TLS traffic can either		Middlebox: A middlebox that interacts with TLS traffic can either
	act as a TLS proxy, intercepting and decrypting the traffic for		act as a TLS proxy, intercepting and decrypting the traffic for
	inspection, or inspect the traffic between TLS peers without		inspection, or inspect the traffic between TLS peers without
	terminating the TLS session.		terminating the TLS session.
	Endpoint Security Agent: An Endpoint Security Agent is a software		Endpoint Security Agent: An Endpoint Security Agent is a software
	installed on endpoint devices that protects them from security		installed on endpoint devices that protects them from security
	threats. It provides features such as malware protection,		threats. It provides features such as malware protection,
	firewall, and intrusion prevention to ensure the device's security		firewall, and intrusion prevention to ensure the device's security
	skipping to change at line 265 ¶		skipping to change at line 266 ¶
	authorities trusted by the IoT devices. Typically, IoT devices have		authorities trusted by the IoT devices. Typically, IoT devices have
	an infrastructure that supports a rapid deployment of updates, and		an infrastructure that supports a rapid deployment of updates, and
	malware agents will have a near-impossible task of similarly		malware agents will have a near-impossible task of similarly
	deploying updates and continuing to mimic the TLS behavior of the IoT		deploying updates and continuing to mimic the TLS behavior of the IoT
	device it has infected.		device it has infected.
	However, if the IoT device has reached end-of-life (EOL) and the IoT		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 [RFC8520] can be used by the MUD manager to		defined in Section 3.6 of [RFC8520] can be used by the MUD manager to
	identify the IoT manufacturer no longer supports the device. The EOL		indicate that the IoT manufacturer no longer supports the device.
	of a device, where the IoT manufacturer no longer supports it, does		The EOL of a device, where the IoT manufacturer no longer supports
	not necessarily mean the device is defective. Instead, it signifies		it, does not necessarily mean the device is defective. Instead, it
	that the device is no longer receiving updates, support, or security		signifies that the device is no longer receiving updates, support, or
	patches, which necessitates replacement and upgrading to next-		security patches, which necessitates replacement and upgrading to
	generation devices to ensure continued functionality, security, and		next-generation devices to ensure continued functionality, security,
	compatibility with modern networks. The network security service		and compatibility with modern networks. The network security service
	will have to rely on other techniques discussed in Section 9 to		will have to rely on other techniques discussed in Section 9 to
	identify malicious connections until the device is replaced.		identify malicious connections until the device is replaced.
	Compromised IoT devices are typically used for launching DDoS attacks		Compromised IoT devices are typically used for launching DDoS attacks
	(Section 3 of [RFC8576]). For example, DDoS attacks like Slowloris		(Section 3 of [RFC8576]). For example, DDoS attacks like Slowloris
	[SLOWLORIS] and Transport Layer Security (TLS) re-negotiation can be		[SLOWLORIS] and Transport Layer Security (TLS) re-negotiation can be
	blocked if the victim's server certificate is not be signed by the		blocked if the victim's server certificate is not be signed by the
	same certifying authorities trusted by the IoT device.		same certifying authorities trusted by the IoT device.
	4. (D)TLS 1.3 Handshake		4. (D)TLS 1.3 Handshake
	skipping to change at line 398 ¶		skipping to change at line 399 ¶
	* List of pre-shared key exchange modes.		* List of pre-shared key exchange modes.
	* List of named groups (DHE or ECDHE) supported by the client.		* List of named groups (DHE or ECDHE) supported by the client.
	* List of signature algorithms the client can validate in X.509		* List of signature algorithms the client can validate in X.509
	server certificates.		server certificates.
	* List of signature algorithms the client is willing to accept for		* List of signature algorithms the client is willing to accept for
	the CertificateVerify message (Section 4.2.3 of [RFC8446]). For		the CertificateVerify message (Section 4.2.3 of [RFC8446]). For
	example, a TLS client implementation can support different sets of		example, a TLS client implementation can support different sets of
	algorithms for certificates and in TLS to signal the capabilities		algorithms for certificates, and it can signal the capabilities in
	in "signature_algorithms_cert" and "signature_algorithms"		the "signature_algorithms_cert" and "signature_algorithms"
	extensions.		extensions.
	* List of supported application protocols (e.g., h3, h2, http/1.1		* List of supported application protocols (e.g., h3, h2, http/1.1
	etc.).		etc.).
	* List of certificate compression algorithms (defined in [RFC8879]).		* List of certificate compression algorithms (defined in [RFC8879]).
	* List of the distinguished names [X501] of acceptable certificate		* List of the distinguished names [X501] of acceptable certificate
	authorities, represented in DER-encoded format [X690] (defined in		authorities, represented in DER-encoded format [X690] (defined in
	Section 4.2.4 of [RFC8446]).		Section 4.2.4 of [RFC8446]).
	skipping to change at line 501 ¶		skipping to change at line 502 ¶
	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: Tirumaleswar Reddy.K		Author: Tirumaleswar Reddy.K
	kondtir@gmail.com		kondtir@gmail.com
			Author: Dan Wing
			danwing@gmail.com
			Author: Blake Anderson
			blake.anderson@cisco.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 profiles		IETF description of an access list to allow (D)TLS profiles
	as matching criteria.		as matching criteria.
	Copyright (c) 2025 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
	skipping to change at line 612 ¶		skipping to change at line 619 ¶
	"TLS versions supported by the client.";		"TLS versions supported by the client.";
	}		}
	leaf-list supported-dtls-version {		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		"A list of trust anchor certificates used by the
	skipping to change at line 913 ¶		skipping to change at line 920 ¶
	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: Tirumaleswar Reddy.K		Author: Tirumaleswar Reddy.K
	kondtir@gmail.com		kondtir@gmail.com
			Author: Dan Wing
			danwing@gmail.com
			Author: Blake Anderson
			blake.anderson@cisco.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) 2025 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
	skipping to change at line 1186 ¶		skipping to change at line 1199 ¶
	constraints, such as avoiding any noticeable differences on the		constraints, such as avoiding any noticeable differences on the
	infected devices and the potential for take-down requests impacting		infected devices and the potential for take-down requests impacting
	their server infrastructure (e.g., certificate revocation by a CA		their server infrastructure (e.g., certificate revocation by a CA
	upon reporting).		upon reporting).
	9.2. Considerations for the "iana-tls-profile" Module		9.2. Considerations for the "iana-tls-profile" Module
	This section follows the template defined in Section 3.7.1 of		This section follows the template defined in Section 3.7.1 of
	[YANG-GUIDELINES].		[YANG-GUIDELINES].
	The "iana-tls-profile" YANG module specified in this document defines		The "iana-tls-profile" YANG module defines a data model that is
	a schema for data can possibly be accessed via network management		designed to be accessed via YANG-based management protocols, such as
	protocols such as NETCONF [RFC6241] or RESTCONF [RFC8040]. These		NETCONF [RFC6241] and RESTCONF [RFC8040]. These protocols have to
	network management protocols are required to use a secure transport		use a secure transport layer (e.g., SSH [RFC4252], TLS [RFC8446], and
	layer and mutual authentication, e.g., SSH [RFC6242] without the		QUIC [RFC9000]) and have to use mutual authentication.
	"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		The Network Configuration Access Control Model (NACM) [RFC8341]
	to restrict access for particular users to a pre-configured subset of		provides the means to restrict access for particular NETCONF or
	all available protocol operations and content.		RESTCONF users to a preconfigured subset of all available NETCONF or
			RESTCONF protocol operations and content.
			There are no particularly sensitive writable data nodes.
			There are no particularly sensitive readable data nodes.
	This YANG module defines YANG enumerations for a public IANA-		This YANG module defines YANG enumerations for a public IANA-
	maintained registry.		maintained registry.
	YANG enumerations are not security-sensitive, as they are statically		YANG enumerations are not security-sensitive, as they are statically
	defined in the publicly-accessible YANG module. IANA MAY deprecate		defined in the publicly accessible YANG module. IANA MAY deprecate
	and/or obsolete enumerations over time as needed to address security		and/or obsolete enumerations over time as needed to address security
	issues.		issues.
	This module does not define any writable-nodes, RPCs, actions, or		There are no particularly sensitive RPC or action operations.
	notifications, and thus the security consideration for such is not
	provided here.		The YANG module defines a set of identities, types, and groupings.
			These nodes are intended to be reused by other YANG modules. The
			module by itself does not expose any data nodes that are writable,
			data nodes that contain read-only state, or RPCs. As such, there are
			no additional security issues related to the YANG module that need to
			be considered.
	9.3. Considerations for the "ietf-acl-tls" Module		9.3. Considerations for the "ietf-acl-tls" Module
	This section follows the template defined in Section 3.7.1 of		This section follows the template defined in Section 3.7.1 of
	[YANG-GUIDELINES].		[YANG-GUIDELINES].
	The "ietf-acl-tls" YANG module specified in this document defines a		The "ietf-acl-tls" YANG module defines a data model that is designed
	schema for data that is designed to be accessed via network		to be accessed via YANG-based management protocols, such as NETCONF
	management protocols such as NETCONF [RFC6241] or RESTCONF [RFC8040].		[RFC6241] and RESTCONF [RFC8040]. These protocols have to use a
	These network management protocols are required to use a secure		secure transport layer (e.g., SSH [RFC4252], TLS [RFC8446], and QUIC
	transport layer and mutual authentication, e.g., SSH [RFC6242]		[RFC9000]) and have to use mutual authentication.
	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.
	Please be aware that this YANG module uses groupings from other YANG		The Network Configuration Access Control Model (NACM) [RFC8341]
	modules that define nodes that may be considered sensitive or		provides the means to restrict access for particular NETCONF or
	vulnerable in network environments. Please review the Security		RESTCONF users to a preconfigured subset of all available NETCONF or
	Considerations for dependent YANG modules for information as to which		RESTCONF protocol operations and content.
	nodes may be considered sensitive or vulnerable in network
	environments.
	All the writable data nodes defined by this module may be considered		There are a number of data nodes defined in this YANG module that are
	sensitive or vulnerable in some network environments. For instance,		writable/creatable/deletable (i.e., "config true", which is the
	the addition or removal of references to trusted anchors, (D)TLS		default). All writable data nodes are likely to be reasonably
	versions, cipher suites, etc., can dramatically alter the implemented		sensitive or vulnerable in some network environments. Write
	security policy. For this reason, the NACM extension "default-deny-		operations (e.g., edit-config) and delete operations to these data
	write" has been set for all data nodes defined in this module.		nodes without proper protection or authentication can have a negative
			effect on network operations. For instance, the addition or removal
			of references to trusted anchors, (D)TLS versions, cipher suites,
			etc., can dramatically alter the implemented security policy. For
			this reason, the NACM extension "default-deny-write" has been set for
			all data nodes defined in this module.
	Some of the readable data nodes defined in this YANG module may be		Some of the readable data nodes defined in this YANG module may be
	considered sensitive or vulnerable in some network environments. It		considered sensitive or vulnerable in some network environments. It
	is thus important to control read access (e.g., via get, get-config,		is thus important to control read access (e.g., via get, get-config,
	or notification) to these data nodes. The YANG module will provide		or notification) to these data nodes. The YANG module will provide
	insights into (D)TLS profiles of the IoT devices, and the privacy		insights into (D)TLS profiles of the IoT devices, and the privacy
	considerations discussed in Section 10 need to be taken into account.		considerations discussed in Section 10 need to be taken into account.
	This module does not define any RPCs, actions, or notifications, and		There are no particularly sensitive RPC or action operations.
	thus the security consideration for such is not provided here.
			This YANG module uses groupings from other YANG modules that define
			nodes that may be considered sensitive or vulnerable in network
			environments. Refer to the Security Considerations for dependent
			YANG modules for information as to which nodes may be considered
			sensitive or vulnerable in network environments.
	9.4. Considerations for the "ietf-mud-tls" Module		9.4. Considerations for the "ietf-mud-tls" Module
	This section follows the template defined in Section 3.7.1 of		This section follows the template defined in Section 3.7.1 of
	[YANG-GUIDELINES].		[YANG-GUIDELINES].
	The "ietf-mud-tls" YANG module specified in this document defines a		The "ietf-mud-tls" YANG module defines a data model that is designed
	schema for data can possibly be accessed via network management		to be accessed via YANG-based management protocols, such as NETCONF
	protocols such as NETCONF [RFC6241] or RESTCONF [RFC8040]. These		[RFC6241] and RESTCONF [RFC8040]. These protocols have to use a
	network management protocols are required to use a secure transport		secure transport layer (e.g., SSH [RFC4252], TLS [RFC8446], and QUIC
	layer and mutual authentication, e.g., SSH [RFC6242] without the		[RFC9000]) and have to use mutual authentication.
	"none" authentication option, Transport Layer Security (TLS)
	[RFC8446] with mutual X.509 authentication, and HTTPS with HTTP
	authentication (Section 11 of [RFC9110]). Note that the YANG module
	is not intended to be accessed via NETCONF and RESTCONF. This has
	already been discussed in [RFC8520], and we are reiterating it here
	for the sake of completeness.
	The Network Access Control Model (NACM) [RFC8341] provides the means		The Network Configuration Access Control Model (NACM) [RFC8341]
	to restrict access for particular users to a pre-configured subset of		provides the means to restrict access for particular NETCONF or
	all available protocol operations and content.		RESTCONF users to a preconfigured subset of all available NETCONF or
			RESTCONF protocol operations and content.
	Please be aware that this YANG module uses groupings from other YANG		There are a number of data nodes defined in this YANG module that are
	modules that define nodes that may be considered sensitive or		writable/creatable/deletable (i.e., "config true", which is the
	vulnerable in network environments. Please review the Security		default). All writable data nodes are likely to be reasonably
	Considerations for dependent YANG modules for information as to which		sensitive or vulnerable in some network environments. Write
	nodes may be considered sensitive or vulnerable in network		operations (e.g., edit-config) and delete operations to these data
	environments.		nodes without proper protection or authentication can have a negative
			effect on network operations. For instance, update that the device
			does not support (D)TLS profile can dramatically alter the
			implemented security policy. For this reason, the NACM extension
			"default-deny-write" has been set for all data nodes defined in this
			module.
	All the writable data nodes defined by this module may be considered		There are no particularly sensitive RPC or action operations.
	sensitive or vulnerable in some network environments. For instance,
	update that the device does not support (D)TLS profile can
	dramatically alter the implemented security policy. For this reason,
	the NACM extension "default-deny-write" has been set for all data
	nodes defined in this module.
	This module does not define any RPCs, actions, or notifications, and		This YANG module uses groupings from other YANG modules that define
	thus the security consideration for such is not provided here.		nodes that may be considered sensitive or vulnerable in network
			environments. Refer to the Security Considerations for dependent
			YANG modules for information as to which nodes may be considered
			sensitive or vulnerable in network environments.
	10. Privacy Considerations		10. Privacy Considerations
	Privacy considerations discussed in Section 16 of [RFC8520] to not		Privacy considerations discussed in Section 16 of [RFC8520] to not
	reveal the MUD URL to an attacker need to be taken into		reveal the MUD URL to an attacker need to be taken into
	consideration. The MUD URL can be stored in a Trusted Execution		consideration. The MUD URL can be stored in a Trusted Execution
	Environment (TEE) for secure operation, enhanced data security, and		Environment (TEE) for secure operation, enhanced data security, and
	prevention of exposure to unauthorized software. The MUD URL MUST be		prevention of exposure to unauthorized software. The MUD URL MUST be
	encrypted and shared only with the authorized components in the		encrypted and shared only with the authorized components in the
	network (see Sections 1.5 and 1.8 of [RFC8520]) so that an on-path		network (see Sections 1.5 and 1.8 of [RFC8520]) so that an on-path
	skipping to change at line 1411 ¶		skipping to change at line 1430 ¶
	should be defined:		should be defined:
	"enum": Replicates the label from the registry.		"enum": Replicates the label from the registry.
	"value": Contains the IANA-assigned value corresponding to the		"value": Contains the IANA-assigned value corresponding to the
	"tls-version" or "dtls-version".		"tls-version" or "dtls-version".
	"description": Replicates the description from the registry.		"description": Replicates the description from the registry.
	"reference": RFC YYYY: <Title of the RFC>, where YYYY is the RFC		"reference": RFC YYYY: <Title of the RFC>, where YYYY is the RFC
	that added the "tls-version" or "dtls-version"		that added the "tls-version" or "dtls-version".
	When a (D)TLS parameter is added to the "ACL (D)TLS Parameters"		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-		registry, a new "type" statement must be added to the iana-tls-
	profile YANG module. The following "type" statement, and		profile YANG module. The following "type" statement, and
	substatements thereof, should be defined:		substatements thereof, should be defined:
	"derived type": Replicates the parameter name from the registry.		"derived type": Replicates the parameter name from the registry.
	"built-in type": Contains the built-in YANG type.		"built-in type": Contains the built-in YANG type.
	skipping to change at line 1475 ¶		skipping to change at line 1494 ¶
	+=======+========+==================+===========+		+=======+========+==================+===========+
	| 1 | dtls12 | DTLS Version 1.2 | [RFC6347] |		| 1 | dtls12 | DTLS Version 1.2 | [RFC6347] |
	+-------+--------+------------------+-----------+		+-------+--------+------------------+-----------+
	| 2 | dtls13 | DTLS Version 1.3 | [RFC9147] |		| 2 | dtls13 | DTLS Version 1.3 | [RFC9147] |
	+-------+--------+------------------+-----------+		+-------+--------+------------------+-----------+
	Table 2		Table 2
	11.5. ACL (D)TLS Parameters Registry		11.5. ACL (D)TLS Parameters Registry
	IANA has created a new registry titled "ACL (D)TLS parameters".		IANA has created a new registry titled "ACL (D)TLS Parameters".
	The values for all the (D)TLS parameters in the registry are defined		The values for all the (D)TLS parameters in the registry are defined
	in the TLS and DTLS IANA registries		in the TLS and DTLS IANA registries
	(https://www.iana.org/assignments/tls-parameters/ and		(https://www.iana.org/assignments/tls-parameters/ and
	https://www.iana.org/assignments/tls-extensiontype-values/) excluding		https://www.iana.org/assignments/tls-extensiontype-values/) excluding
	the tls-version and dtls-version parameters. Further assignments are		the tls-version and dtls-version parameters. Further assignments are
	to be made through Expert Review [RFC8126]. Experts must ensure that		to be made through Expert Review [RFC8126]. Experts must ensure that
	the (D)TLS parameter in a new registration is one that has been		the (D)TLS parameter in a new registration is one that has been
	standardized by the IETF. The registry is expected to be updated		standardized by the IETF. The registry is expected to be updated
	periodically, primarily when a new (D)TLS parameter is standardized		periodically, primarily when a new (D)TLS parameter is standardized
	skipping to change at line 1502 ¶		skipping to change at line 1521 ¶
	+============================+=============+========+==============+		+============================+=============+========+==============+
	| extension-type | uint16 | Number | Extension |		| extension-type | uint16 | Number | Extension |
	| | | | type |		| | | | type |
	+----------------------------+-------------+--------+--------------+		+----------------------------+-------------+--------+--------------+
	| supported-group | uint16 | Number | Supported |		| supported-group | uint16 | Number | Supported |
	| | | | group |		| | | | group |
	+----------------------------+-------------+--------+--------------+		+----------------------------+-------------+--------+--------------+
	| signature-algorithm | uint16 | Number | Signature |		| signature-algorithm | uint16 | Number | Signature |
	| | | | algorithm |		| | | | algorithm |
	+----------------------------+-------------+--------+--------------+		+----------------------------+-------------+--------+--------------+
	| psk-key-exchange-mode | uint8 | Number | pre-shared |		| psk-key-exchange-mode | uint8 | Number | Pre-shared |
	| | | | key exchange |		| | | | key exchange |
	| | | | mode |		| | | | mode |
	+----------------------------+-------------+--------+--------------+		+----------------------------+-------------+--------+--------------+
	| application-protocol | string | String | Application |		| application-protocol | string | String | Application |
	| | | | protocol |		| | | | protocol |
	+----------------------------+-------------+--------+--------------+		+----------------------------+-------------+--------+--------------+
	| cert-compression-algorithm | uint16 | Number | Certificate |		| cert-compression-algorithm | uint16 | Number | Certificate |
	| | | | compression |		| | | | compression |
	| | | | algorithm |		| | | | algorithm |
	+----------------------------+-------------+--------+--------------+		+----------------------------+-------------+--------+--------------+
	| cipher-algorithm | uint16 | Number | Cipher Suite |		| cipher-algorithm | uint16 | Number | Cipher suite |
	+----------------------------+-------------+--------+--------------+		+----------------------------+-------------+--------+--------------+
	| tls-version | enumeration | String | TLS version |		| tls-version | enumeration | String | TLS version |
	+----------------------------+-------------+--------+--------------+		+----------------------------+-------------+--------+--------------+
	| dtls-version | enumeration | String | DTLS version |		| dtls-version | enumeration | String | DTLS version |
	+----------------------------+-------------+--------+--------------+		+----------------------------+-------------+--------+--------------+
	Table 3		Table 3
	11.6. MUD Extensions Registry		11.6. MUD Extensions Registry
	skipping to change at line 1540 ¶		skipping to change at line 1559 ¶
	[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate		[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
	Requirement Levels", BCP 14, RFC 2119,		Requirement Levels", BCP 14, RFC 2119,
	DOI 10.17487/RFC2119, March 1997,		DOI 10.17487/RFC2119, March 1997,
	<https://www.rfc-editor.org/info/rfc2119>.		<https://www.rfc-editor.org/info/rfc2119>.
	[RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,		[RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,
	DOI 10.17487/RFC3688, January 2004,		DOI 10.17487/RFC3688, January 2004,
	<https://www.rfc-editor.org/info/rfc3688>.		<https://www.rfc-editor.org/info/rfc3688>.
			[RFC4252] Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH)
			Authentication Protocol", RFC 4252, DOI 10.17487/RFC4252,
			January 2006, <https://www.rfc-editor.org/info/rfc4252>.
	[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security		[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
	(TLS) Protocol Version 1.2", RFC 5246,		(TLS) Protocol Version 1.2", RFC 5246,
	DOI 10.17487/RFC5246, August 2008,		DOI 10.17487/RFC5246, August 2008,
	<https://www.rfc-editor.org/info/rfc5246>.		<https://www.rfc-editor.org/info/rfc5246>.
	[RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed.,		[RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed.,
	and A. Bierman, Ed., "Network Configuration Protocol		and A. Bierman, Ed., "Network Configuration Protocol
	(NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011,		(NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011,
	<https://www.rfc-editor.org/info/rfc6241>.		<https://www.rfc-editor.org/info/rfc6241>.
	[RFC6242] Wasserman, M., "Using the NETCONF Protocol over Secure
	Shell (SSH)", RFC 6242, DOI 10.17487/RFC6242, June 2011,
	<https://www.rfc-editor.org/info/rfc6242>.
	[RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer		[RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer
	Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347,		Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347,
	January 2012, <https://www.rfc-editor.org/info/rfc6347>.		January 2012, <https://www.rfc-editor.org/info/rfc6347>.
	[RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF		[RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF
	Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017,		Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017,
	<https://www.rfc-editor.org/info/rfc8040>.		<https://www.rfc-editor.org/info/rfc8040>.
	[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC		[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
	2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,		2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
	skipping to change at line 1594 ¶		skipping to change at line 1613 ¶
	[RFC8701] Benjamin, D., "Applying Generate Random Extensions And		[RFC8701] Benjamin, D., "Applying Generate Random Extensions And
	Sustain Extensibility (GREASE) to TLS Extensibility",		Sustain Extensibility (GREASE) to TLS Extensibility",
	RFC 8701, DOI 10.17487/RFC8701, January 2020,		RFC 8701, DOI 10.17487/RFC8701, January 2020,
	<https://www.rfc-editor.org/info/rfc8701>.		<https://www.rfc-editor.org/info/rfc8701>.
	[RFC8879] Ghedini, A. and V. Vasiliev, "TLS Certificate		[RFC8879] Ghedini, A. and V. Vasiliev, "TLS Certificate
	Compression", RFC 8879, DOI 10.17487/RFC8879, December		Compression", RFC 8879, DOI 10.17487/RFC8879, December
	2020, <https://www.rfc-editor.org/info/rfc8879>.		2020, <https://www.rfc-editor.org/info/rfc8879>.
	[RFC9110] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke,		[RFC9000] Iyengar, J., Ed. and M. Thomson, Ed., "QUIC: A UDP-Based
	Ed., "HTTP Semantics", STD 97, RFC 9110,		Multiplexed and Secure Transport", RFC 9000,
	DOI 10.17487/RFC9110, June 2022,		DOI 10.17487/RFC9000, May 2021,
	<https://www.rfc-editor.org/info/rfc9110>.		<https://www.rfc-editor.org/info/rfc9000>.
	[RFC9147] Rescorla, E., Tschofenig, H., and N. Modadugu, "The		[RFC9147] Rescorla, E., Tschofenig, H., and N. Modadugu, "The
	Datagram Transport Layer Security (DTLS) Protocol Version		Datagram Transport Layer Security (DTLS) Protocol Version
	1.3", RFC 9147, DOI 10.17487/RFC9147, April 2022,		1.3", RFC 9147, DOI 10.17487/RFC9147, April 2022,
	<https://www.rfc-editor.org/info/rfc9147>.		<https://www.rfc-editor.org/info/rfc9147>.
	[RFC9640] Watsen, K., "YANG Data Types and Groupings for		[RFC9640] Watsen, K., "YANG Data Types and Groupings for
	Cryptography", RFC 9640, DOI 10.17487/RFC9640, October		Cryptography", RFC 9640, DOI 10.17487/RFC9640, October
	2024, <https://www.rfc-editor.org/info/rfc9640>.		2024, <https://www.rfc-editor.org/info/rfc9640>.
	[X690] ITU-T, "Information technology - ASN.1 encoding Rules:		[X690] ITU-T, "Information technology - ASN.1 encoding Rules:
	Specification of Basic Encoding Rules (BER), Canonical		Specification of Basic Encoding Rules (BER), Canonical
	Encoding Rules (CER) and Distinguished Encoding Rules		Encoding Rules (CER) and Distinguished Encoding Rules
	(DER)", ITU-T Recommendation X.690, July 2002,		(DER)", ITU-T Recommendation X.690, 2021,
	<https://www.itu.int/rec/T-REC-X.690-200207-S/en>.		<https://www.itu.int/rec/T-REC-X.690-202102-I/en>.
	12.2. Informative References		12.2. Informative References
	[CLEAR-AS-MUD]		[CLEAR-AS-MUD]
	Hamza, A., Ranathunga, D., Gharakheili, H. H., Roughan,		Hamza, A., Ranathunga, D., Gharakheili, H. H., Roughan,
	M., and V. Sivaraman, "Clear as MUD: Generating,		M., and V. Sivaraman, "Clear as MUD: Generating,
	Validating and Applying IoT Behaviorial Profiles		Validating and Applying IoT Behaviorial Profiles
	(Technical Report)", arXiv:1804.04358,		(Technical Report)", arXiv:1804.04358,
	DOI 10.48550/arXiv.1804.04358, April 2018,		DOI 10.48550/arXiv.1804.04358, April 2018,
	<https://arxiv.org/pdf/1804.04358.pdf>.		<https://arxiv.org/pdf/1804.04358.pdf>.
	[CRYPTO-VULNERABILITY]		[CRYPTO-VULNERABILITY]
	Perez, B., "Exploiting the Windows CryptoAPI		Perez, B., "Exploiting the Windows CryptoAPI
	Vulnerability", January 2020,		Vulnerability", January 2020,
	<https://media.defense.gov/2020/Jan/14/2002234275/-1/-1/0/		<https://securityboulevard.com/2020/01/exploiting-the-
	CSA-WINDOWS-10-CRYPT-LIB-20190114.PDF>.		windows-cryptoapi-vulnerability/>.
	[EVE] Cisco, "Encrypted Visibility Engine", Cisco Secure		[EVE] Cisco, "Encrypted Visibility Engine", Cisco Secure
	Firewall documentation, <https://secure.cisco.com/secure-		Firewall documentation, <https://secure.cisco.com/secure-
	firewall/docs/encrypted-visibility-engine>.		firewall/docs/encrypted-visibility-engine>.
	[IoT-PROFILE]		[IoT-PROFILE]
	Tschofenig, H., Fossati, T., and M. Richardson, "TLS/DTLS		Tschofenig, H., Fossati, T., and M. Richardson, "TLS/DTLS
	1.3 Profiles for the Internet of Things", Work in		1.3 Profiles for the Internet of Things", Work in
	Progress, Internet-Draft, draft-ietf-uta-tls13-iot-		Progress, Internet-Draft, draft-ietf-uta-tls13-iot-
	profile-13, 3 March 2025,		profile-13, 3 March 2025,
	skipping to change at line 1709 ¶		skipping to change at line 1728 ¶
	[RFC8447] Salowey, J. and S. Turner, "IANA Registry Updates for TLS		[RFC8447] Salowey, J. and S. Turner, "IANA Registry Updates for TLS
	and DTLS", RFC 8447, DOI 10.17487/RFC8447, August 2018,		and DTLS", RFC 8447, DOI 10.17487/RFC8447, August 2018,
	<https://www.rfc-editor.org/info/rfc8447>.		<https://www.rfc-editor.org/info/rfc8447>.
	[RFC8472] Popov, A., Ed., Nystroem, M., and D. Balfanz, "Transport		[RFC8472] Popov, A., Ed., Nystroem, M., and D. Balfanz, "Transport
	Layer Security (TLS) Extension for Token Binding Protocol		Layer Security (TLS) Extension for Token Binding Protocol
	Negotiation", RFC 8472, DOI 10.17487/RFC8472, October		Negotiation", RFC 8472, DOI 10.17487/RFC8472, October
	2018, <https://www.rfc-editor.org/info/rfc8472>.		2018, <https://www.rfc-editor.org/info/rfc8472>.
			[RFC8484] Hoffman, P. and P. McManus, "DNS Queries over HTTPS
			(DoH)", RFC 8484, DOI 10.17487/RFC8484, October 2018,
			<https://www.rfc-editor.org/info/rfc8484>.
	[RFC8576] Garcia-Morchon, O., Kumar, S., and M. Sethi, "Internet of		[RFC8576] Garcia-Morchon, O., Kumar, S., and M. Sethi, "Internet of
	Things (IoT) Security: State of the Art and Challenges",		Things (IoT) Security: State of the Art and Challenges",
	RFC 8576, DOI 10.17487/RFC8576, April 2019,		RFC 8576, DOI 10.17487/RFC8576, April 2019,
	<https://www.rfc-editor.org/info/rfc8576>.		<https://www.rfc-editor.org/info/rfc8576>.
	[RFC8613] Selander, G., Mattsson, J., Palombini, F., and L. Seitz,		[RFC8613] Selander, G., Mattsson, J., Palombini, F., and L. Seitz,
	"Object Security for Constrained RESTful Environments		"Object Security for Constrained RESTful Environments
	(OSCORE)", RFC 8613, DOI 10.17487/RFC8613, July 2019,		(OSCORE)", RFC 8613, DOI 10.17487/RFC8613, July 2019,
	<https://www.rfc-editor.org/info/rfc8613>.		<https://www.rfc-editor.org/info/rfc8613>.
	skipping to change at line 1742 ¶		skipping to change at line 1765 ¶
	DOI 10.17487/RFC9462, November 2023,		DOI 10.17487/RFC9462, November 2023,
	<https://www.rfc-editor.org/info/rfc9462>.		<https://www.rfc-editor.org/info/rfc9462>.
	[RFC9463] Boucadair, M., Ed., Reddy.K, T., Ed., Wing, D., Cook, N.,		[RFC9463] Boucadair, M., Ed., Reddy.K, T., Ed., Wing, D., Cook, N.,
	and T. Jensen, "DHCP and Router Advertisement Options for		and T. Jensen, "DHCP and Router Advertisement Options for
	the Discovery of Network-designated Resolvers (DNR)",		the Discovery of Network-designated Resolvers (DNR)",
	RFC 9463, DOI 10.17487/RFC9463, November 2023,		RFC 9463, DOI 10.17487/RFC9463, November 2023,
	<https://www.rfc-editor.org/info/rfc9463>.		<https://www.rfc-editor.org/info/rfc9463>.
	[SLOWLORIS]		[SLOWLORIS]
	ha.ckers.org security lab, "Slowloris HTTP DoS", Wayback		Wikipedia, "Slowloris (cyber attack)", December 2024,
	Machine archive, March 2015,		<https://en.wikipedia.org/w/index.php?title=Slowloris_(cyb
	<https://web.archive.org/web/20150315054838/		er_attack)&oldid=1263305193>.
	http://ha.ckers.org/slowloris/>.
	[TLS-ESNI] Rescorla, E., Oku, K., Sullivan, N., and C. A. Wood, "TLS		[TLS-ESNI] Rescorla, E., Oku, K., Sullivan, N., and C. A. Wood, "TLS
	Encrypted Client Hello", Work in Progress, Internet-Draft,		Encrypted Client Hello", Work in Progress, Internet-Draft,
	draft-ietf-tls-esni-23, 19 February 2025,		draft-ietf-tls-esni-24, 20 March 2025,
	<https://datatracker.ietf.org/doc/html/draft-ietf-tls-		<https://datatracker.ietf.org/doc/html/draft-ietf-tls-
	esni-23>.		esni-24>.
	[X501] "Information Technology - Open Systems Interconnection -		[X501] "Information Technology - Open Systems Interconnection -
	The Directory: Models", ITU-T Recommendation X.501,		The Directory: Models", ITU-T Recommendation X.501,
	November 1993,		October 2019,
	<https://www.itu.int/rec/T-REC-X.501-199311-S/en>.		<https://www.itu.int/rec/T-REC-X.501-201910-I/en>.
	[YANG-GUIDELINES]		[YANG-GUIDELINES]
	Bierman, A., Boucadair, M., and Q. Wu, "Guidelines for		Bierman, A., Boucadair, M., and Q. Wu, "Guidelines for
	Authors and Reviewers of Documents Containing YANG Data		Authors and Reviewers of Documents Containing YANG Data
	Models", Work in Progress, Internet-Draft, draft-ietf-		Models", Work in Progress, Internet-Draft, draft-ietf-
	netmod-rfc8407bis-22, 14 January 2025,		netmod-rfc8407bis-22, 14 January 2025,
	<https://datatracker.ietf.org/doc/html/draft-ietf-netmod-		<https://datatracker.ietf.org/doc/html/draft-ietf-netmod-
	rfc8407bis-22>.		rfc8407bis-22>.
	Acknowledgments		Acknowledgments
End of changes. 37 change blocks.
	109 lines changed or deleted		131 lines changed or added
This html diff was produced by rfcdiff 1.48.