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/ On Sun, Mar 6, 2022 at 7:26 PM Christopher Wood <[email protected]> wrote: > 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 protected]> 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 > > [email protected] > > https://www.ietf.org/mailman/listinfo/secdir > > wiki: https://trac.ietf.org/trac/sec/wiki/SecDirReview > > _______________________________________________ > secdir mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/secdir > wiki: https://trac.ietf.org/trac/sec/wiki/SecDirReview >
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ OPSAWG mailing list [email protected] https://www.ietf.org/mailman/listinfo/opsawg
