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? _______________________________________________ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg