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 > <nore...@ietf.org> wrote: > > 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? > > > _______________________________________________ > secdir mailing list > sec...@ietf.org > https://www.ietf.org/mailman/listinfo/secdir > wiki: https://trac.ietf.org/trac/sec/wiki/SecDirReview _______________________________________________ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
