Early Review of draft-ietf-opsawg-mud-iot-dns-considerations-03
review-ietf-opsawg-mud-iot-dns-considerations-03-secdir-early-wood-2022-03-06-00

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?