Manufacturer Usage Description (MUD) for TLS and DTLS Profiles for Internet of Things (IoT) Devices
Extracted elements (24)
A network-designated DoH/DoT server is required for MUD policy enforcement because IoT devices that use a pre-configured DNS resolver bypass the network's ability to monitor and filter DNS queries, which is a common malware technique to evade MUD-based filtering.
MUD (D)TLS ACL matching uses software-based ACLs rather than hardware TCAM because matching on binary data, strings, and (D)TLS parameters requires flexible string matching not available in fixed-length bit-matching hardware. The DNS extension in MUD (RFC 8520) has the same requirement.
MUD is extended to include (D)TLS profile parameters because Layer 3/4 ACLs in RFC 8520 are insufficient for broad communication patterns. Observable (D)TLS handshake parameters allow a network security service to identify malware without decrypting traffic, complementing existing MUD ACLs rather than replacing them.
New ACL TLS Version and ACL DTLS Version registries are created separately from the main TLS IANA registries because the TLS and DTLS IANA registries do not maintain (D)TLS version numbers. This allows the 'iana-tls-profile' YANG module to be automatically updated by IANA when new (D)TLS versions are standardized.
If a (D)TLS parameter observed in a session is not in the MUD profile but is recognized by the firewall, the firewall can identify unexpected (D)TLS usage and take action such as blocking the session or raising an alert for quarantine.
If an IoT device uses a DNS resolver not signaled by the network (via DHCP, DNR RFC 9463, or DDR RFC 9462), MUD policy enforcement based on domain names cannot be applied. Use of a non-network-designated DNS resolver is generally incompatible with MUD.
In (D)TLS 1.3, all handshake messages except the ClientHello are encrypted, so a passive middlebox can only inspect fields visible in the ClientHello and ServerHello (supported versions, named groups, cipher suites, signature algorithms, extension list, and chosen cipher). Full handshake inspection of TLS 1.3 requires the middlebox to act as a proxy.
If the MUD (D)TLS profile includes any parameters susceptible to attacks (e.g., weaker cryptographic parameters), an alert MUST be triggered to the firewall vendor and the IoT device owner or administrator.
The (D)TLS profile parameters defined in the YANG module MUST NOT include GREASE values for extension types, named groups, signature algorithms, (D)TLS versions, pre-shared key exchange modes, cipher suites, and any other TLS parameters defined in future RFCs.
When the 'ietf-mud-tls' extension is present, only 'accept' or 'drop' actions SHOULD be included with the (D)TLS profile, consistent with the actions allowed in RFC 8520 Section 2.
The MUD URL MUST be encrypted and shared only with authorized network components so that an on-path attacker cannot read it and identify the IoT device model, which would reveal applicable vulnerabilities. The MUD URL can be stored in a Trusted Execution Environment (TEE).
The use of (D)TLS proxies for full handshake inspection is NOT RECOMMENDED whenever possible due to the privacy tradeoff: decrypting traffic exposes personally identifiable information and protected health information. Alternatives include bypass rules for well-known services, IoT device rejection of proxy sessions, and object security (e.g., OSCORE/RFC 8613).
The (D)TLS profile for an IoT device includes: profile name, supported (D)TLS versions, cipher suites, extension types, trust anchor certificates, PSK key exchange modes, named groups, signature algorithms (for certificates and CertificateVerify), application protocols, certificate compression algorithms, and distinguished names of acceptable certificate authorities.
The IANA-maintained YANG module 'iana-tls-profile' defines typedefs for all observable (D)TLS parameters: extension-type (uint16), supported-group (uint16), signature-algorithm (uint16), psk-key-exchange-mode (uint8), application-protocol (string), cert-compression-algorithm (uint16), cipher-algorithm (uint16), tls-version (enumeration: tls12=1, tls13=2), dtls-version (enumeration: dtls12=1, dtls13=2).
The YANG module 'ietf-acl-tls' augments the 'ietf-acl' ACL YANG module (RFC 8519) with a 'client-profiles' container containing a list of 'tls-dtls-profile' entries, each keyed by name, carrying all (D)TLS observable parameters as leaf-lists typed from the 'iana-tls-profile' module.
The YANG module 'ietf-mud-tls' augments the 'ietf-mud' module with a single boolean leaf 'is-tls-dtls-profile-supported' (default false) that signals whether an IoT device's MUD file implements the 'match-on-tls-dtls' ACL model feature.
TLS version identification in ClientHello: TLS 1.2 uses 'legacy_version' 0x0303; TLS 1.3 uses 'legacy_version' 0x0303 plus a 'supported_versions' extension containing 0x0304. DTLS 1.2 uses 0xfefd; DTLS 1.3 uses 0xfefd plus 'supported_versions' extension with 0x0304.
IANA created the 'ACL (D)TLS Parameters' registry with Expert Review policy, initially populated with: extension-type (uint16), supported-group (uint16), signature-algorithm (uint16), psk-key-exchange-mode (uint8), application-protocol (string), cert-compression-algorithm (uint16), cipher-algorithm (uint16), tls-version (enumeration), dtls-version (enumeration). Updates to this registry trigger corresponding updates to the 'iana-tls-profile' YANG module.
IANA created the 'ACL DTLS Version Codes' registry with Expert Review policy. Initial entries: value 1 = dtls12 (RFC 6347), value 2 = dtls13 (RFC 9147). Used as valid values for the 'dtls-version' parameter in the 'iana-tls-profile' YANG module.
IANA created the 'ACL TLS Version Codes' registry with Expert Review policy. Initial entries: value 1 = tls12 (RFC 5246), value 2 = tls13 (RFC 8446). Used as valid values for the 'tls-version' parameter in the 'iana-tls-profile' YANG module.
IANA registered the MUD extension name 'ietf-mud-tls' in the 'MUD Extensions' IANA registry, along with three YANG module namespace URIs (iana-tls-profile, ietf-acl-tls, ietf-mud-tls) in the IETF XML Registry and the YANG Module Names registry.
The middlebox MUST adhere to the invariants in RFC 8446 Section 9.3 when acting as a compliant (D)TLS proxy. While malware mimicking legitimate IoT device (D)TLS profiles is challenging due to per-model and per-manufacturer variability, it is not impossible; network security services should also use contextual network data (domain name, IP reputation, anomaly detection) to detect false negatives.
The writable data nodes in 'ietf-acl-tls' (trust anchors, (D)TLS versions, cipher suites, etc.) are sensitive: unauthorized write or delete operations can dramatically alter the implemented security policy. The NACM extension 'default-deny-write' is set for all data nodes in this module.
YANG modules defined in this document must be accessed via NETCONF or RESTCONF over a secure transport (SSH, TLS, or QUIC) with mutual authentication. NACM (RFC 8341) provides access control for NETCONF/RESTCONF users.