Re: [OPSAWG] [secdir] Secdir early review of draft-ietf-opsawg-mud-iot-dns-considerations-03

[Ben Schwartz <[e-mail]>]

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 <[e-mail]> 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 <
> [e-mail]> 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
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/secdir
> > wiki: https://trac.ietf.org/trac/sec/wiki/SecDirReview
>
> _______________________________________________
> secdir mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/secdir
> wiki: https://trac.ietf.org/trac/sec/wiki/SecDirReview
>