Subject: [OPSAWG] Secdir early review of draft-ietf-opsawg-mud-iot-dns-considerations-03

From: Christopher Wood via Datatracker <[email-masked]>
Date: Sun, 06 Mar 2022 16:21:35 -0800

Reviewer: Christopher Wood
Review result: Not Ready

Reviewer: Christopher Wood
Review result: Has issues

General comments:

In general, the problem statement and motivation for this draft -- and the
techniques in Section 3 in particular -- seems underspecified. For example,
what are the requirements for the firewall or MUD controller name<>address
mappings? Is this mapping ever allowed to be stale? If so, how stale can it be?
What is the threat model for the controller when trying to enforce a name-based
policy and update its mappings? Does it consider an attacker that tries to
interfere with how the mappings are constructed, either via direct queries to
DNS or via reverse DNS queries through in-addr.arpa? What privacy
considerations are relevant in the presence of this (or other) attackers? What
sort of assumptions are made about the content or service that is accessed
after these DNS queries complete?

Specific comments:

Section 1.

   Use of a DNS name rather than IP address in the ACL has many
   advantages: not only does the layer of indirection permit the mapping
   of name to IP address to be changed over time, it also generalizes
   automatically to IPv4 and IPv6 addresses, as well as permitting
   loading balancing of traffic by many different common ways, including
   geography.

I might generalize this a bit to also include multi-CDN deployments for
services, wherein load balancing might account for geography, load, etc.

Section 3.

   In order to compensate for this, the MUD controller SHOULD regularly
   do DNS lookups.  These lookups need to be rate limited in order to
   avoid load.  It may be necessary to avoid recursive DNS servers in
   order to avoid receiving cached data.

This seems to suggest that controllers should, in the name of "security",
intentionally bypass resolver caches to ensure their view of the name<>address
mappings is never stale. This doesn't seem like great advice, considering (1)
the data should always be assumed to be stale (this is a distributed system,
after all) and (2) any benign firewall operator may simply try to increase the
rate of queries to drive down the probability of working with stale data. That
may in turn either overload the authoritative server, or cause the MUD
controller to be rate limited, yielding the opposite of the desired effect.

Section 4.2

   Those names are often within some third-party Content-Distribution-
   Network (CDN) system, or may be arbitrary names in a cloud-provider
   storage system such as Amazon S3 (such [AmazonS3], or [Akamai]).

Does this mean to say that the names are unpredictably chosen by the content
provider, and not by the content owner? If so, I might rephrase it as such.

Section 4.3

   Some CDNs make all customer content at a single URL (such as
   s3.amazonaws.com).  This seems to be ideal from a MUD point of view:
   a completely predictable URL.  The problem is that a compromised
   device could then connect to any S3 bucket, potentially attacking
   other buckets.

What does "attacking other buckets" mean here? Does it mean increasing number
of reads to those buckets? Or perhaps _writing_ to those buckets? I don't know
what sort of access control techniques are typically used here, but the latter,
i.e., people writing to arbitrary buckets, would be surprising to me. In any
case, I would clarify what is meant here, along with what assumptions are made
about the content providers themselves.

Section 5.

   There are significant privacy issues with having IoT devices sending
   their DNS queries to an outside entity.  Doing it over a secure
   transport (DoT/DoH) is clearly better than doing so on port 53.  The
   providers of the secure resolver service will, however, still see the
   IoT device queries.

This seems to be assuming a particular threat model that may not be universally
applicable. It may not be the case that using a public resolver will lead to
"significant privacy issues." I might clarify the assumed threat model here,
rather than prescribe one for all users of this document.

Moreover, if something like Oblivious DoH were used, would this still be an
issue? ODoH is mentioned later on in the privacy considerations, but I think it
warrants mention here as well.

Section 6.5.

   Use of public QuadX resolver instead of the provided DNS resolver,
   whether Do53, DoT or DoH is discouraged.  Should the network provide
   such a resolver for use, then there is no reason not to use it, as
   the network operator has clearly thought about this.

I would push back on this. As I understand the situation, some ISP recursive
resolvers essentially forward queries onwards to public (QuadX) resolvers.
What's the difference, then, between using the public resolver directly and the
network-provided resolver? (This points back to the previous comment on the
assumed threat model.)

Section 6.5.

   The recommendation here is to do this only when the provided
   resolvers provide no answers to any queries at all, and do so
   repeatedly.  The use of the operator provided resolvers SHOULD be
   retried on a periodic basis, and once they answer, there should be no
   further attempts to contact public resolvers.

I think this needs a better description of the threat model in order to make
sense. What if, for example, some attacker basically blocked all answers from
provided resolvers, forcing usage of public resolvers? Is that in scope or not?

---

From: Christopher Wood <[email-masked]>
Date: Sun, 6 Mar 2022 16:25:46 -0800

Oops. I manually entered the review result in the datatracker form. The intended review result is “Not Ready."

> On Mar 6, 2022, at 4:21 PM, Christopher Wood via Datatracker <[email-masked]> wrote:
> 
> _______________________________________________
> secdir mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/secdir
> wiki: https://trac.ietf.org/trac/sec/wiki/SecDirReview

---

From: Ben Schwartz <[email-masked]>
Date: Mon, 7 Mar 2022 11:47:12 -0500

I reviewed [1] this draft at version 01, but my concerns largely stand with
the current version.

The fundamental issue here, in my view, is that the urn:ietf:params:mud:dns
permission is not compatible with the desired threat model.  A correct
solution would be to recommend against this permission, and introduce a new
one that provides explicit coupling between DNS resolution, transport
setup, and the MUD gateway (e.g. using a SOCKS5 proxy).

[1] https://mailarchive.ietf.org/arch/msg/dnsop/PNJy-kf-6CErJrKf5NSwvTv0srk/

---

From: Michael Richardson <[email-masked]>
Date: Mon, 07 Mar 2022 17:27:27 -0500

> setup, and the MUD gateway (e.g. using a SOCKS5 proxy).

The MUD controller is a thing that programs ACLs into a standard gateway.
I don't think we have a "MUD gateway" in any of the architectures.

Yes, it would be a great idea if such a thing was deployable.
Which currently shipping home routers include SOCKS5 proxy?

Is SOCKSv5 it a standard part of MATTER, or Google Fiber, or Xfinity, or
free.fr routers?

How would the IoT device negotiate the authentication for the firewall
traversal, if that was part of the SOCKSv5?   It would be totally awesome if
IoT vendors could rely on that?

Unfortunately, recommending against urn:ietf:params:mud:dns is recommending
against RFC8520.

--
Michael Richardson <[email-masked]>   . o O ( IPv6 IøT consulting )
           Sandelman Software Works Inc, Ottawa and Worldwide

---

From: Ben Schwartz <[email-masked]>
Date: Mon, 7 Mar 2022 21:27:38 -0500

> I don't think we have a "MUD gateway" in any of the architectures.

We are speaking about a new architecture, because the existing architecture
doesn't really work for named destinations.  However, if we wanted to stick
close to that architecture, the MUD controller could contain the proxy
server, and place an ACL in the gateway restricting certain MUD devices to
speak only to the MUD controller.

> Is SOCKSv5 it a standard part of MATTER, or Google Fiber, or Xfinity, or

Do those all support MUD today?  I haven't encountered much in the way of
deployed support for MUD.

If we are trying to devise solutions that are compatible with some large
existing install base, then that certainly raises the difficulty.
Otherwise, we are free to consider the difficulty of implementation, which
I believe can be kept extremely low.

BTW, I'm not claiming that a transport proxy is the only possible answer.
Another option would be to proxy MUD DNS through the MUD controller, so it
can restrict the allowed DNS queries and install ACLs before returning the
AAAA/A records.

> IoT vendors could rely on that?

I'm not sure what you mean.  Personally, I imagined that the proxy would
only accept connections from local IPs that have MUD profiles, and would
enforce the relevant MUD policies.

> against RFC8520.

It's certainly unfortunate when an RFC contains an oversight, but this
seems to me like a problem that is easily remedied.

---

From: Michael Richardson <[email-masked]>
Date: Sat, 26 Mar 2022 20:32:15 -0400

> setup, and the MUD gateway (e.g. using a SOCKS5 proxy).

I have been struggling to find a way to deal with your comments.
https://github.com/mcr/iot-mud-dns-considerations/pull/2 is the 
beginnings of a recommendation to use SOCKS5 if it is present on 
networks.  I don't think that we have a way to do that.

Perhaps there is some discovery of SOCKS5 in some vendor DHCP option, 
but I haven't found that yet.

---

From: Ben Schwartz <[email-masked]>
Date: Mon, 28 Mar 2022 19:00:59 +0000

> but I haven't found that yet.

Local SOCKS5 proxies are conventionally discovered via WPAD [1], which
returns a PAC file [2].  I'm no great fan of WPAD, but it is widely
implemented in browsers and OSes.

I don't mean to claim that SOCKS5 specifically, or domain-oriented
transport proxies generally, are the right solution here.  My point is that
the MUD gateway architecture described here is fatally flawed.
Specifically, I'm focused on this text:

   Aside from the list of records being incomplete, the list may have
   changed between the time that the MUD controller did the lookup and
   the time that the IoT device does the lookup, and this change can
   result in a failure for the ACL to match.

   In order to compensate for this, the MUD controller SHOULD regularly
   do DNS lookups in order to get never have stale data.  These lookups
   need to be rate limited in order to avoid load.  It may be necessary
   to avoid local recursive DNS servers.  The MUD controller SHOULD
   incorporate its own recursive caching DNS server.  Properly designed
   recursive servers should cache data for many minutes to days, while
   the underlying DNS data can change at a higher frequency, providing
   different answers to different queries!

   A MUD controller that is aware of which recursive DNS server that the
   IoT device will use can instead query that server on a periodic
   basis.

The problem description here is accurate, but the proposed MUD controller
behaviors are not reliably compatible with RFC 8520-compliant devices, so
they cannot safely be deployed.  The only reliable solution is to update
the allowed IPs based on the specific DNS responses that are being used by
the device's connections.  This could either be done implicitly (via a
transport proxy) or explicitly (by ensuring the MUD controller _is_ the
client's DNS resolver, and adding IP ACLs before returning any DNS response
containing IP addresses).

This also touches on another issue with MUD DNS support: RFC 8520 does not
clearly define any rule regarding the allowed DNS QNAMEs.  This enables
arbitrary data flows to be tunneled through the DNS to arbitrary
destinations.  In my view, this is a very large hole in the MUD
protections.  A transport proxy or tighter DNS binding would also help to
close this loophole.

[1] https://datatracker.ietf.org/doc/html/draft-ietf-wrec-wpad-01
[2]
https://developer.mozilla.org/en-US/docs/Web/HTTP/Proxy_servers_and_tunneling/Proxy_Auto-Configuration_PAC_file

---

From: "Independent Submissions Editor (Eliot Lear)" <[email-masked]>
Date: Mon, 28 Mar 2022 21:25:58 +0200

I think there are two things going on here.

First, there is a need for the controller to be tightly bound with the 
resolver.  Thus it is aware of what is returned to the device.  How long 
the device uses that information should be governed by the upper bound 
of DNS caching semantics and stateful access mechanisms.

The second thing going on here is that the device needs to do a new 
lookup if the TTL on a record has expired, and it has unexpectedly lost 
connectivity, something that can happen on the Internet with or without 
MUD.  In fact, MUD is hardly the issue here.  The issue is whether you 
can have DNS-based ACLs that can function.  Here the enforcement point 
has something to say to make that happen, because resilience 
requirements on the client will dictate it happening.

Eliot

On 28.03.22 21:00, Ben Schwartz wrote:
>
>
> On Sat, Mar 26, 2022 at 8:32 PM Michael Richardson 
> <[email-masked] <mailto:[email-masked]>> wrote:
>
> transport proxies generally, are the right solution here.  My point is 
> that the MUD gateway architecture described here is fatally flawed. 
> The problem description here is accurate, but the proposed MUD 
> controller behaviors are not reliably compatible with RFC 
> 8520-compliant devices, so they cannot safely be deployed.  The only 
> reliable solution is to update the allowed IPs based on the specific 
> DNS responses that are being used by the device's connections.  This 
> could either be done implicitly (via a transport proxy) or explicitly 
> (by ensuring the MUD controller _is_ the client's DNS resolver, and 
> adding IP ACLs before returning any DNS response containing IP addresses).
>
> This also touches on another issue with MUD DNS support: RFC 8520 does 
> not clearly define any rule regarding the allowed DNS QNAMEs.  This 
> enables arbitrary data flows to be tunneled through the DNS to 
> arbitrary destinations.  In my view, this is a very large hole in the 
> MUD protections.  A transport proxy or tighter DNS binding would also 
> help to close this loophole.
>
> OPSAWG mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/opsawg

---

From: Eliot Lear <[email-masked]>
Date: Mon, 28 Mar 2022 21:27:44 +0200

My apologies.  This should have gone out under my name, not under that 
of the ISE.  The ISE has no interest in this.

Eliot

On 28.03.22 21:25, Independent Submissions Editor (Eliot Lear) wrote:
> resolver.  Thus it is aware of what is returned to the device.  How 
> long the device uses that information should be governed by the upper 
> bound of DNS caching semantics and stateful access mechanisms.
>
> lookup if the TTL on a record has expired, and it has unexpectedly 
> lost connectivity, something that can happen on the Internet with or 
> without MUD.  In fact, MUD is hardly the issue here.  The issue is 
> whether you can have DNS-based ACLs that can function.  Here the 
> enforcement point has something to say to make that happen, because 
> resilience requirements on the client will dictate it happening.
>
> Eliot
>
>> Local SOCKS5 proxies are conventionally discovered via WPAD [1], 
>> which returns a PAC file [2].  I'm no great fan of WPAD, but it is 
>> widely implemented in browsers and OSes.
>>
>> transport proxies generally, are the right solution here.  My point 
>> is that the MUD gateway architecture described here is fatally 
>> flawed. Specifically, I'm focused on this text:
>>
>> This also touches on another issue with MUD DNS support: RFC 8520 
>> does not clearly define any rule regarding the allowed DNS QNAMEs.  
>> This enables arbitrary data flows to be tunneled through the DNS to

---

From: Michael Richardson <[email-masked]>
Date: Mon, 28 Mar 2022 18:18:41 -0400

> implemented in browsers and OSes.

Yeah, that's not going to fly.
  } [1] https://datatracker.ietf.org/doc/html/draft-ietf-wrec-wpad-01 
1) draft-ietf-wrec-wpad is a 22 year old ID which specifies use of a
   private-use DHCP option (252).
   
   While one think one can get away with an SRV entry, that requires
   local DNS to be working, which is exactly the kind of thing that
   IoT manufacturers are having trouble relying upon.
   (Yes, if a MUD controller is present, we can expect local DNS
   to be more reliable, but it is exactly in the opposite case that there is
   concern) 
   
2) Once you find the CFile, according to the URL you dug up 
   (Thank you. The link in the 22 year old ID is long dead)

    > https://developer.mozilla.org/en-US/docs/Web/HTTP/Proxy_servers_and_tunneling/Proxy_Auto-Configuration_PAC_file

The PAC file is javascript?

-- 
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-