Manufacturer Usage
Description (MUD) (D)TLS Profiles for IoT DevicesNokiaIndiakondtir@gmail.comCitrix Systems, Inc.4988 Great America PkwySanta ClaraCA95054USAdanwing@gmail.comCisco Systems, Inc.170 West Tasman DrSan JoseCA95134USAblake.anderson@cisco.comOPSAWG WGThis memo extends the Manufacturer Usage Description (MUD)
specification to incorporate (D)TLS profile parameters. This allows a
network security service to identify unexpected (D)TLS usage, which can
indicate the presence of unauthorized software or malware on an
endpoint.Encryption is necessary to enhance the privacy of end users using IoT
devices. TLS and DTLS are the dominant protocols
(counting all (D)TLS versions) providing encryption for IoT device
traffic. Unfortunately, in conjunction with IoT applications' rise of
encryption, malware authors are also using encryption which thwarts
network-based analysis such as deep packet inspection (DPI). Other
mechanisms are thus needed to help detecting malware running on an IoT
device.Malware frequently uses proprietary libraries for its activities, and
those libraries are reused much like any other software engineering
project. indicates that there are
observable differences in how malware uses encryption compared with how
non-malware uses encryption. There are several interesting findings
specific to (D)TLS which were found common to malware: Older and weaker cryptographic parameters (e.g.,
TLS_RSA_WITH_RC4_128_SHA).TLS server name indication (SNI) extension and server certificates are composed of
subjects with characteristics of a domain generation algorithm (DGA)
(e.g., 'www.33mhwt2j.net').Higher use of self-signed certificates compared with typical
legitimate software.Discrepancies in the SNI TLS extension and the DNS names in the
SubjectAltName (SAN) X.509 extension in the server certificate
message.Discrepancies in the key exchange algorithm and the client public
key length in comparison with legitimate flows. As a reminder, the
Client Key Exchange message has been removed from TLS 1.3.Lower diversity in TLS client advertised extensions compared to
legitimate clients.Using privacy enhancing technologies like Tor, Psiphon, Ultrasurf
(see ), and evasion techniques
such as ClientHello randomization.Using DNS-over-HTTPS (DoH) to
avoid detection by malware DNS filtering services . Specifically, malware may not use the
DoH server provided by the local network.If observable (D)TLS profile parameters are used, the following
functions are possible which have a positive impact on the local network
security:Permit intended DTLS or TLS use and block malicious DTLS or TLS
use. This is superior to the layers 3 and 4 ACLs of Manufacturer
Usage Description Specification (MUD)
which are not suitable for broad communication patterns.Ensure TLS certificates are valid. Several TLS deployments have
been vulnerable to active Man-In-The-Middle (MITM) attacks because
of the lack of certificate validation or vulnerability in the
certificate validation function (see ). By observing (D)TLS profile
parameters, a network element can detect when the TLS SNI mismatches
the SubjectAltName and when the server's certificate is invalid. In
TLS 1.2, the ClientHello, ServerHello and Certificate messages are
all sent in clear-text. This check is not possible with TLS 1.3,
which encrypts the Certificate message thereby hiding the server
identity from any intermediary. In TLS 1.3, the server certificate
validation functions should be executed within an on-path TLS proxy,
if such a proxy exists.Support new communication patterns. An IoT device can learn a new
capability, and the new capability can change the way the IoT device
communicates with other devices located in the local network and
Internet. There would be an inaccurate policy if an IoT device
rapidly changes the IP addresses and domain names it communicates
with while the MUD ACLs were slower to update (see ). In such a case, observable (D)TLS
profile parameters can be used to permit intended use and to block
malicious behavior from the IoT device.The YANG module specified in of this
document is an extension of YANG Data Model for Network Access Control
Lists (ACLs) to enhance MUD to model observable (D)TLS profile parameters.
Using these (D)TLS profile parameters, an active MUD-enforcing network
security service (e.g., firewall) can identify MUD non-compliant (D)TLS
behavior indicating outdated cryptography or malware. This detection can
prevent malware downloads, block access to malicious domains, enforce
use of strong ciphers, stop data exfiltration, etc. In addition,
organizations may have policies around acceptable ciphers and
certificates for the websites the IoT devices connect to. Examples
include no use of old and less secure versions of TLS, no use of
self-signed certificates, deny-list or accept-list of Certificate
Authorities, valid certificate expiration time, etc. These policies can
be enforced by observing the (D)TLS profile parameters. Network security
services can use the IoT device's (D)TLS profile parameters to identify
legitimate flows by observing (D)TLS sessions, and can make inferences
to permit legitimate flows and to block malicious or insecure flows. The
proposed technique is also suitable in deployments where decryption
techniques are not ideal due to privacy concerns, non-cooperating
end-points, and expense.The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP 14
when, and
only when, they appear in all capitals, as shown here."(D)TLS" is used for statements that apply to both Transport Layer
Security and Datagram Transport Layer
Security . Specific terms are used for any
statement that applies to either protocol alone.'DoH/DoT' refers to DNS-over-HTTPS and/or DNS-over-TLS.In Enterprise networks, protection and detection are typically done
both on end hosts and in the network. Host security agents have deep
visibility on the devices where they are installed, whereas the network
has broader visibility. Installing host security agents may not be a
viable option on IoT devices, and network-based security is an efficient
means to protect such IoT devices. If the IoT device supports a MUD
(D)TLS profile, the (D)TLS profile parameters of the IoT device can be
used by a middlebox to detect and block malware communication, while at
the same time preserving the privacy of legitimate uses of encryption.
The middlebox need not proxy (D)TLS but can passively observe the
parameters of (D)TLS handshakes from IoT devices and gain visibility
into TLS 1.2 parameters and partial visibility into TLS 1.3
parameters.Malicious agents can try to use the (D)TLS profile parameters of
legitimate agents to evade detection, but it becomes a challenge to
mimic the behavior of various IoT device types and IoT device models
from several manufacturers. In other words, malware developers will have
to develop malicious agents per IoT device type, manufacturer and model,
infect the device with the tailored malware agent and will have keep up
with updates to the device's (D)TLS profile parameters over time.
Furthermore, the malware's command and control server certificates need
to be signed by the same certifying authorities trusted by the IoT
devices. Typically, IoT devices have an infrastructure that supports a
rapid deployment of updates, and malware agents will have a
near-impossible task of similarly deploying updates and continuing to
mimic the TLS behavior of the IoT device it has infected. However, if
the IoT device has reached end-of-life and the IoT manufacturer will not
issue a firmware or software update to the Thing or will not update the
MUD file, the "is-supported" attribute defined in Section 3.6 of can be used by the MUD manager to identify the
IoT manufacturer no longer supports the device.The end-of-life of a device does not necessarily mean that it is
defective; rather, it denotes a need to replace and upgrade the network
to next-generation devices for additional functionality. The network
security service will have to rely on other techniques discussed in
to identify malicious connections until
the device is replaced.Compromised IoT devices are typically used for launching DDoS attacks
(Section 3 of ). For example, DDoS attacks
like Slowloris and Transport Layer Security (TLS) re-negotiation can be
blocked if the victim's server certificate is not be signed by the same
certifying authorities trusted by the IoT device.In (D)TLS 1.3, full (D)TLS handshake inspection is not possible since
all (D)TLS handshake messages excluding the ClientHello message are
encrypted. (D)TLS 1.3 has introduced new extensions in the handshake
record layers called Encrypted Extensions. Using these extensions
handshake messages will be encrypted and network security services (such
as a firewall) are incapable to decipher the handshake, and thus cannot
view the server certificate. However, the ClientHello and ServerHello
still have some fields visible, such as the list of supported versions,
named groups, cipher suites, signature algorithms and extensions in
ClientHello, and chosen cipher in the ServerHello. For instance, if the
malware uses evasion techniques like ClientHello randomization, the
observable list of cipher suites and extensions offered by the malware
agent in the ClientHello message will not match the list of cipher
suites and extensions offered by the legitimate client in the
ClientHello message, and the middlebox can block malicious flows without
acting as a (D)TLS 1.3 proxy.To obtain more visibility into negotiated TLS 1.3 parameters, a
middlebox can act as a (D)TLS 1.3 proxy. A middlebox can act as a
(D)TLS proxy for the IoT devices owned and managed by the IT team in
the Enterprise network and the (D)TLS proxy must meet the security and
privacy requirements of the organization. In other words, the scope of
middlebox acting as a (D)TLS proxy is restricted to Enterprise network
owning and managing the IoT devices. The middlebox would have to
follow the behaviour detailed in Section 9.3 of to act as a compliant (D)TLS 1.3 proxy.To further increase privacy, Encrypted Client Hello (ECH) extension
prevents passive observation
of the TLS Server Name Indication extension and other potentially
sensitive fields, such as the ALPN . To
effectively provide that privacy protection, ECH extension needs to be
used in conjunction with DNS encryption (e.g., DoH). A middlebox
(e.g., firewall) passively inspecting ECH extension cannot observe the
encrypted SNI nor observe the encrypted DNS traffic. The middlebox
acting as a (D)TLS 1.3 proxy that does not support ECH extension will
act as if connecting to the public name and it follows the behaviour
discussed in Section 6.1.6 of
to securely signal the client to disable ECH.A common usage pattern for certain type of IoT devices (e.g., light
bulb) is for it to "call home" to a service that resides on the public
Internet, where that service is referenced through a domain name (A or
AAAA record). As discussed in Manufacturer Usage Description
Specification , because these devices
tend to require access to very few sites, all other access should be
considered suspect. If an IoT device is pre-configured to use a DNS
resolver not signaled by the network, the MUD policy enforcement point
is moved to that resolver, which cannot enforce the MUD policy based
on domain names (Section 8 of ). If the
DNS query is not accessible for inspection, it becomes quite difficult
for the infrastructure to suspect anything. Thus the use of a DNS
resolver not signaled by the network is incompatible with MUD in
general. A network-designated DoH/DoT server is necessary to allow MUD
policy enforcement on the local network, for example, using the
techniques specified in and
.This document specifies a YANG module for representing (D)TLS
profile. The (D)TLS profile YANG module provides a method for network
security services to observe the (D)TLS profile parameters in the (D)TLS
handshake to permit intended use and to block malicious behavior. This
module uses the cryptographic types defined in . See for (D)TLS 1.2 and for DTLS 1.3
recommendations related to IoT devices, and for additional (D)TLS 1.2 recommendations.A companion YANG module is defined to include a collection of (D)TLS
parameters and (D)TLS versions maintained by IANA: "iana-tls-profile"
().The (D)TLS parameters in each (D)TLS profile include the
following:Profile name(D)TLS versions supported by the IoT device.List of supported cipher suites. For (D)TLS1.2, recommends AEAD ciphers for IoT
devices.List of supported extension typesList of trust anchor certificates used by the IoT device. If the
server certificate is signed by one of the trust anchors, the
middlebox continues with the connection as normal. Otherwise, the
middlebox will react as if the server certificate validation has
failed and takes appropriate action (e.g, block the (D)TLS session).
An IoT device can use a private trust anchor to validate a server's
certificate (e.g., the private trust anchor can be preloaded at
manufacturing time on the IoT device and the IoT device fetches the
firmware image from the Firmware server whose certificate is signed
by the private CA). This empowers the middlebox to reject TLS
sessions to servers that the IoT device does not trust.List of SPKI pin set pre-configured on the client to validate
self-signed server certificates or raw public keys. A SPKI pin set
is a cryptographic digest to "pin" public key information in a
manner similar to HTTP Public Key Pinning (HPKP) . If SPKI pin set is present in the (D)TLS
profile of a IoT device and the server certificate does not pass the
PKIX certification path validation, the middlebox computes the SPKI
Fingerprint for the public key found in the server's certificate (or
in the raw public key, if the server provides that instead). If a
computed fingerprint exactly matches one of the SPKI pin sets in the
(D)TLS profile, the middlebox continues with the connection as
normal. Otherwise, the middlebox will act on the SPKI validation
failure and takes appropriate action.Cryptographic hash algorithm used to generate the SPKI
pinsetsList of pre-shared key exchange modesList of named groups (DHE or ECDHE) supported by the clientList of signature algorithms the client can validate in X.509
server certificatesList of signature algorithms the client is willing to accept for
CertificateVerify message (Section 4.2.3 of ). For example, a TLS client implementation
can support different sets of algorithms for certificates and in TLS
to signal the capabilities in "signature_algorithms_cert" and
"signature_algorithms" extensions.List of supported application protocols (e.g., h3, h2, http/1.1
etc.)List of certificate compression algorithms (defined in )List of the distinguished names of
acceptable certificate authorities, represented in DER-encoded
format (defined in Section 4.2.4 of
)GREASE sends random values on TLS
parameters to ensure future extensibility of TLS extensions. Similar
random values might be extended to other TLS parameters. Thus, the
(D)TLS profile parameters defined in the YANG module by this document
MUST NOT include the GREASE values for extension types, named groups,
signature algorithms, (D)TLS versions, pre-shared key exchange modes,
cipher suites and for any other TLS parameters defined in future
RFCs.The (D)TLS profile does not include parameters like compression
methods for data compression, recommends
disabling TLS-level compression to prevent compression-related attacks.
In TLS 1.3, only the "null" compression method is allowed (Section 4.1.2
of ).This document augments the "ietf-acl" ACL YANG module defined in
for signaling the IoT device (D)TLS
profile. This document defines the YANG module "ietf-acl-tls", which
has the following tree structure:The TLS and DTLS IANA registries are available from
and .The values for all the parameters in the "iana-tls-profile" YANG
module are defined in the TLS and DTLS IANA registries excluding the
tls-version, dtls-version, spki-pin-set, and certificate-authority
parameters. The values of spki-pin-set and certificate-authority
parameters will be specific to the IoT device.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
ClientHello message is used for version negotiation. However in (D)TLS
1.3, the "supported_versions" extension is used by the client to
indicate which versions of (D)TLS it supports. TLS 1.3 ClientHello
messages are identified as having a "legacy_version" of 0x0303 and a
"supported_versions" extension present with 0x0304 as the highest
version. DTLS 1.3 ClientHello messages are identified as having a
"legacy_version" of 0xfefd and a "supported_versions" extension
present with 0x0304 as the highest version.In order to ease updating the "iana-tls-profile" YANG module with
future (D)TLS versions, new (D)TLS version registries are defined in
and . Whenever a new (D)TLS protocol version
is defined, the registry will be updated using expert review; the
"iana-tls-profile" YANG module will be automatically updated by
IANA.The "iana-tls-profile" YANG module is defined as follows:This document augments the "ietf-mud" MUD YANG module to indicate
whether the device supports (D)TLS profile. If the "ietf-mud-tls"
extension is supported by the device, MUD file is assumed to implement
the "match-on-tls-dtls" ACL model feature defined in this
specification. Furthermore, only "accept" or "drop" actions SHOULD be
included with the (D)TLS profile similar to the actions allowed in
Section 2 of .This document defines the YANG module "ietf-mud-tls", which has the
following tree structure:The model is defined as follows:The following text outlines the rules for a network security service
(e.g., firewall) to follow to process the MUD (D)TLS Profile:If the (D)TLS parameter observed in a (D)TLS session is not
specified in the MUD (D)TLS profile and the parameter is recognized
by the firewall, it can identify unexpected (D)TLS usage, which can
indicate the presence of unauthorized software or malware on an
endpoint. The firewall can take several actions like block the
(D)TLS session or raise an alert to quarantine and remediate the
compromised device. For example, if the cipher suite
TLS_RSA_WITH_AES_128_CBC_SHA in the ClientHello message is not
specified in the MUD (D)TLS profile and the cipher suite is
recognized by the firewall, it can identify unexpected TLS
usage.If the (D)TLS parameter observed in a (D)TLS session is not
specified in the MUD (D)TLS profile and the (D)TLS parameter is not
recognized by the firewall, it can ignore the unrecognized parameter
and the correct behavior is not to block the (D)TLS session. The
behaviour is functionally equivalent to the compliant TLS middlebox
description in Section 9.3 of to
ignore all unrecognized cipher suites, extensions, and other
parameters. For example, if the cipher suite
TLS_CHACHA20_POLY1305_SHA256 in the ClientHello message is not
specified in the MUD (D)TLS profile and the cipher suite is not
recognized by the firewall, it can ignore the unrecognized cipher
suite.Deployments update at different rates, so an updated MUD (D)TLS
profile may support newer parameters. If the firewall does not
recognize the newer parameters, an alert should be triggered to the
firewall vendor and the IoT device owner or administrator. A
firewall must be readily updatable, so that when new parameters in
the MUD (D)TLS profile are discovered that are not recognized by the
firewall, it can be updated quickly. Most importantly, if the
firewall is not readily updatable, its protection efficacy to
identify emerging malware will decrease with time. For example, if
the cipher suite TLS_AES_128_CCM_8_SHA256 specified in the MUD
(D)TLS profile is not recognized by the firewall, an alert will be
triggered. Similarly, if the (D)TLS version specified in the MUD
file is not recognized by the firewall, an alert will be
triggered.The example below contains (D)TLS profile parameters for a IoT device
used to reach servers listening on port 443 using TCP transport. JSON
encoding of YANG modelled data is used to
illustrate the example.The following illustrates the example scenarios for processing the
above profile:If the extension type "encrypt_then_mac" (code point 22) in the ClientHello message is recognized by
the firewall, it can identify unexpected TLS usage.If the extension type "token_binding" (code point 24) in the MUD (D)TLS profile is not recognized
by the firewall, it can ignore the unrecognized extension. Because
the extension type "token_binding" is specified in the profile, an
alert will be triggered to the firewall vendor and the IoT device
owner or administrator to notify the firewall is not up to date.Security considerations in need to be
taken into consideration. The middlebox must adhere to the invariants
discussed in Section 9.3 of to act as a
compliant proxy.Although it is challenging for a malware to mimic the TLS behavior of
various IoT device types and IoT device models from several
manufacturers, malicious agents have a very low probability of using the
same (D)TLS profile parameters as legitimate agents on the IoT device to
evade detection. Network security services should also rely on
contextual network data to detect false negatives. In order to detect
such malicious flows, anomaly detection (deep learning techniques on
network data) can be used to detect malicious agents using the same
(D)TLS profile parameters as legitimate agent on the IoT device. In
anomaly detection, the main idea is to maintain rigorous learning of
"normal" behavior and where an "anomaly" (or an attack) is identified
and categorized based on the knowledge about the normal behavior and a
deviation from this normal behavior.Privacy considerations discussed in Section 16 of to not reveal the MUD URL to an attacker need
to be taken into consideration. The MUD URL can be stored in Trusted
Execution Environment (TEE) for secure operation, enhanced data
security, and prevent exposure to unauthorized software.Full handshake inspection () requires a
TLS proxy device which needs to decrypt traffic between the IoT device
and its server(s). There is a tradeoff between privacy of the data
carried inside TLS (especially e.g., personally identifiable information
and protected health information) and efficacy of endpoint security. It
is strongly RECOMMENDED to avoid a TLS proxy whenever possible. For
example, an enterprise firewall administrator can configure the
middlebox to bypass TLS proxy functionality or payload inspection for
connections destined to specific well-known services. Alternatively, a
IoT device could be configured to reject all sessions that involve proxy
servers to specific well-known services. In addition, mechanisms based
on object security can be used by IoT devices to enable end-to-end
security and the middlebox will not have any access to the packet data.
For example, Object Security for Constrained RESTful Environments
(OSCORE) is a proposal that protects CoAP
messages by wrapping them in the COSE format .This document requests IANA to register the following URIs in the
"ns" subregistry within the "IETF XML Registry" : IANA is requested to create an IANA-maintained YANG Module called
"iana-tls-profile", based on the contents of , which will allow for new (D)TLS parameters
and (D)TLS versions to be added to "client-profile". The registration
procedure will be Expert Review, as defined by .This document requests IANA to register the following YANG modules
in the "YANG Module Names" subregistry
within the "YANG Parameters" registry.IANA is requested to create an the initial version of the
IANA-maintained YANG Module called "iana-tls-profile", based on the
contents of , which will allow for new
(D)TLS parameters and (D)TLS versions to be added. IANA is requested
to add this note:tls-version and dtls-version values must not be directly added
to the iana-tls-profile YANG module. They must instead be
respectively added to the "ACL TLS Version Codes", and "ACL DTLS
Version Codes" registries.(D)TLS parameters must not be directly added to the
iana-tls-profile YANG module. They must instead be added to the
"ACL (D)TLS Parameters" registry.When a 'tls-version' or 'dtls-version' value is respectively added
to the "ACL TLS Version Codes" or "ACL DTLS Version Codes" registry, a
new "enum" statement must be added to the iana-tls-profile YANG
module. The following "enum" statement, and substatements thereof,
should be defined:Replicates the label from the
registry.Contains the IANA-assigned value
corresponding to the 'tls-version' or 'dtls-version'.Replicates the description
from the registry.Replicates the reference from
the registry and adds the title of the document.When a (D)TLS parameter is added to "ACL (D)TLS Parameters"
registry, a new "type" statement must be added to the iana-tls-profile
YANG module. The following "type" statement, and substatements
thereof, should be defined:Replicates the parameter
name from the registry.Contains the built-in
YANG type.Replicates the description
from the registry.When the iana-tls-profile YANG module is updated, a new "revision"
statement must be added in front of the existing revision
statements.IANA is requested to add this note to "ACL TLS Version Codes", "ACL
DTLS Version Codes", and "ACL (D)TLS Parameters" registries:When this registry is modified, the YANG module
iana-tls-profile must be updated as defined in [RFCXXXX].The registration procedure for "ietf-acl-tls" YANG module will be
Specification Required, as defined by .IANA is requested to create a new registry titled "ACL TLS Version
Codes". Codes in this registry are used as valid values of
'tls-version' parameter. Further assignments are to be made through
Expert Review .IANA is requested to create a new registry titled "ACL DTLS Version
Codes". Codes in this registry are used as valid values of
'dtls-version' parameter. Further assignments are to be made through
Expert Review .IANA is requested to create a new registry titled "ACL (D)TLS
parameters".The values for all the (D)TLS parameters in the registry are
defined in the TLS and DTLS IANA registries (
and )
excluding the tls-version, dtls-version, spki-pin-set and
certificate-authority parameters. Further assignments are to be made
through Expert Review . The registry is
initially populated with the following parameters:IANA is requested to create a new MUD Extension Name "ietf-mud-tls"
in the MUD Extensions IANA registry .Thanks to Flemming Andreasen, Shashank Jain, Michael Richardson,
Piyush Joshi, Eliot Lear, Harsha Joshi, Qin Wu, Mohamed Boucadair, Ben
Schwartz, Eric Rescorla, Panwei William, Nick Lamb and Nick Harper for
the discussion and comments.Information technology - ASN.1 encoding Rules: Specification
of Basic Encoding Rules (BER), Canonical Encoding Rules (CER) and
Distinguished Encoding Rules (DER)ITU-TDeciphering Malware’s use of TLS (without
Decryption)CiscoCiscoCiscoInformation Technology - Open Systems Interconnection - The
Directory: ModelsClear as MUD: Generating, Validating and Applying IoT
Behaviorial ProfilesTLS Beyond the Browser: Combining End Host and Network Data
to Understand Application BehaviorCiscoCiscoExploiting the Windows CryptoAPI VulnerabilityCiscoFirst-ever malware strain spotted abusing new DoH (DNS over
HTTPS) protocolCisco