Subject: [secdir] 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.