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

[Ben Schwartz <[e-mail]>]

On Sat, Mar 26, 2022 at 8:32 PM Michael Richardson <[e-mail]>
wrote:

> On 2022-03-07 11:47, Ben Schwartz wrote:
> > 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).
>
> I have been struggling to find a way to deal with your comments.
> https://github.com/mcr/iot-mud-dns-considerations/pull/2 is the
> beginnings of a recommendation to use SOCKS5 if it is present on
> networks.  I don't think that we have a way to do that.
>
> Perhaps there is some discovery of SOCKS5 in some vendor DHCP option,
> but I haven't found that yet.
>

Local SOCKS5 proxies are conventionally discovered via WPAD [1], which
returns a PAC file [2].  I'm no great fan of WPAD, but it is widely
implemented in browsers and OSes.

I don't mean to claim that SOCKS5 specifically, or domain-oriented
transport proxies generally, are the right solution here.  My point is that
the MUD gateway architecture described here is fatally flawed.
Specifically, I'm focused on this text:

   Aside from the list of records being incomplete, the list may have
   changed between the time that the MUD controller did the lookup and
   the time that the IoT device does the lookup, and this change can
   result in a failure for the ACL to match.

   In order to compensate for this, the MUD controller SHOULD regularly
   do DNS lookups in order to get never have stale data.  These lookups
   need to be rate limited in order to avoid load.  It may be necessary
   to avoid local recursive DNS servers.  The MUD controller SHOULD
   incorporate its own recursive caching DNS server.  Properly designed
   recursive servers should cache data for many minutes to days, while
   the underlying DNS data can change at a higher frequency, providing
   different answers to different queries!

   A MUD controller that is aware of which recursive DNS server that the
   IoT device will use can instead query that server on a periodic
   basis.

The problem description here is accurate, but the proposed MUD controller
behaviors are not reliably compatible with RFC 8520-compliant devices, so
they cannot safely be deployed.  The only reliable solution is to update
the allowed IPs based on the specific DNS responses that are being used by
the device's connections.  This could either be done implicitly (via a
transport proxy) or explicitly (by ensuring the MUD controller _is_ the
client's DNS resolver, and adding IP ACLs before returning any DNS response
containing IP addresses).

This also touches on another issue with MUD DNS support: RFC 8520 does not
clearly define any rule regarding the allowed DNS QNAMEs.  This enables
arbitrary data flows to be tunneled through the DNS to arbitrary
destinations.  In my view, this is a very large hole in the MUD
protections.  A transport proxy or tighter DNS binding would also help to
close this loophole.

[1] https://datatracker.ietf.org/doc/html/draft-ietf-wrec-wpad-01
[2]
https://developer.mozilla.org/en-US/docs/Web/HTTP/Proxy_servers_and_tunneling/Proxy_Auto-Configuration_PAC_file