Summary

  • RFC 9761 adds a manufacturer-declared TLS and DTLS profile to MUD, giving a firewall an expected-behaviour reference rather than proof of endpoint integrity.
  • Its enforcement rule is asymmetric: a known but undeclared parameter may justify action; a parameter unknown to both profile and firewall must not be blocked solely for being unknown; a declared value unknown to the firewall exposes stale inspection.
  • TLS 1.3, ECH and encrypted DNS reduce passive evidence. A proxy can recover visibility only by creating a separate privacy, ownership and certificate-validation boundary.

The firewall had a simple reason to distrust the packet: the ClientHello contained a value absent from the stored profile. It also had a more embarrassing reason: its own parser did not know what the value meant.

Those two absences are not the same fact. RFC 9761 refuses to let a security appliance turn its ignorance into a universal denial rule. If the observed parameter is absent from the device's MUD profile but recognized by the firewall, it can be treated as unexpected and can support an alert, quarantine or block. If the parameter is absent from the profile and unrecognized by the firewall, the correct response is not to block solely on that basis. The value may belong to a legitimate protocol extension that the inspection layer has not learned yet.

That distinction looks narrow. In practice it decides whether a control system can survive change.

A declaration of expected behaviour

RFC 8520 starts from a useful property of purpose-built devices: a light, sensor or controller usually needs a much smaller communication surface than a general-purpose computer. A manufacturer can publish a Manufacturer Usage Description, and a local network can translate that description into access policy. The architecture supplies a URL, a signed description and a manager that retrieves and interprets it. It does not transfer final authority from the operator to the manufacturer.

RFC 9761 extends that idea into the encrypted transport layer. Its ietf-acl-tls model augments the generic ACL model in RFC 8519. A profile can name TLS or DTLS versions, cipher suites, extension types, supported groups, signature algorithms, pre-shared-key exchange modes, ALPN protocols, trust anchors, acceptable certificate authorities and certificate-compression algorithms. The associated IANA-maintained module gives those fields a shared vocabulary.

This is more precise than saying “the device uses TLS”. A model expected to offer TLS 1.3, two cipher suites and a particular group can be distinguished from software that suddenly offers an obsolete RSA suite or an unfamiliar extension. But precision does not change the nature of the evidence. The profile is a manufacturer's statement about expected observable behaviour. A live handshake is an observation. The comparison is an inference. None is remote attestation of the code actually executing.

Four states, not one checkbox

The operational model needs at least two questions. Was the observed value declared in the current profile? Does the firewall's current generation recognize it?

When both answers are yes, policy can continue. The match says that this parameter belongs to the expected set; it does not say the process is benign. Malware can imitate ordinary cipher and extension lists.

When the profile says no but the firewall says yes, the deviation has meaning. RFC 9761 says it can indicate unauthorized software or malware. The word “can” carries the uncertainty. A legitimate firmware update may have moved ahead of the published profile; a compromised process may have changed the ClientHello; or a profile may have been bound to the wrong model. Blocking can be locally justified, but the receipt should name which known parameter differed and which policy owner chose the consequence.

When the profile says yes but the firewall says no, the device declaration has moved ahead of the inspector. The parameter is ignored for matching, the session is allowed under the RFC's extensibility posture, and an alert should reach the firewall vendor and device owner. The asset needing remediation is the control layer.

The fourth state is the hardest: neither profile nor firewall knows the value. Blocking would reward old middleware for remaining old. RFC 9761 instead follows the compliant middlebox rule in RFC 8446: ignore unrecognized cipher suites, extensions and other parameters. Record uncertainty, update the parser and re-evaluate when the value becomes known. Do not invent malicious meaning from a missing dictionary entry.

GREASE is the maintenance test

RFC 8701 deliberately sends reserved values so that implementations continuously prove they can tolerate unknown extensions. RFC 9761 therefore says GREASE values must not be included in the device profile. If a firewall treats each such value as a profile violation, it defeats the mechanism designed to keep TLS extensible.

The rule has an economic dimension. A fail-closed inspector exports its maintenance backlog to every endpoint. Vendors can then decide when new protocol values become usable merely by delaying parser updates. A fail-open path with explicit alerting leaves the local operator aware of uncertainty without giving the middlebox a permanent constitutional veto.

IANA's TLS parameters and YANG parameters are current coordination records. The MUD registry records the shared MUD namespaces and extensions. These records can settle names and assignments. They cannot prove that a deployed firewall has loaded the current generation, that a device implements the value or that traffic achieved its purpose.

Encryption shrinks the witness

The comparison surface also changes with protocol version. In TLS and DTLS 1.2, ClientHello, ServerHello and Certificate messages are visible in cleartext. In TLS 1.3—and correspondingly in DTLS 1.3—the certificate and most handshake messages are encrypted. A passive firewall still sees portions of ClientHello and ServerHello, but it cannot inspect the complete profile or validate the server certificate from the wire alone.

ECH can hide SNI and other sensitive ClientHello fields. Encrypted DNS can remove the name lookup from passive view. A device using its own encrypted resolver may therefore bypass the location where domain-based MUD policy was expected to operate. DDR and DNR can designate encrypted resolvers while retaining an explicit network decision, but their use is another fact to verify, not a general answer.

RFC 9761 permits fuller TLS 1.3 inspection through a proxy only for enterprise-owned and managed IoT devices, subject to the organization's security and privacy requirements. It also says such proxies are not recommended whenever possible. That caution matters. A proxy can expose handshake and application material, but it becomes a trust endpoint, changes certificate-validation placement and may handle personal or health information. More visibility is not free evidence.

RFC 9325 supplies current TLS and DTLS security recommendations; RFC 8613 shows a different design in which OSCORE-protected application objects can remain end-to-end confidential even if an intermediary participates at another layer. Neither document makes a deployment choice for the operator. They make the choices and tradeoffs harder to conceal.

A matching profile can still lie by omission

RFC 9761 is candid that malicious software may copy a legitimate profile. Device-model specificity, trusted certificate authorities, destination reputation and frequent updates make imitation harder, not impossible. A conforming ClientHello therefore cannot be used as a clean bill of health.

The evidence chain must retain the MUD URL and file hash, signature result, profile revision, device-model binding, firmware generation, observed parameter code point, firewall parser and registry generation, recognition result, destination context, proxy state, local decision and endpoint follow-up. Application completion belongs at the end, not inside the profile-match field.

The is-supported state deserves similar discipline. A manufacturer can mark a device as no longer supported. That changes expectations about future profile and firmware updates. It does not prove the device is defective today. End of life is a risk input, not a verdict.

This is where Heng Lu's distinction among reality layers becomes operational. A standard, a registry assignment, a signed declaration, a parser rule, a packet and a service outcome are different objects. Running-code primacy means checking the generation actually executing. A minimum common specification with localized future decision supplies shared semantics without pretending that the standards body owns each block, proxy exception or remediation decision.

RFC 9761 is strongest when used as a calibrated sensor. It narrows what “unexpected” means and forces the gatekeeper to disclose when the uncertainty belongs to itself.