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

["Independent Submissions Editor (Eliot Lear)" <[e-mail]>]

I think there are two things going on here.

First, there is a need for the controller to be tightly bound with the 
resolver.  Thus it is aware of what is returned to the device.  How long 
the device uses that information should be governed by the upper bound 
of DNS caching semantics and stateful access mechanisms.

The second thing going on here is that the device needs to do a new 
lookup if the TTL on a record has expired, and it has unexpectedly lost 
connectivity, something that can happen on the Internet with or without 
MUD.  In fact, MUD is hardly the issue here.  The issue is whether you 
can have DNS-based ACLs that can function.  Here the enforcement point 
has something to say to make that happen, because resilience 
requirements on the client will dictate it happening.

Eliot

On 28.03.22 21:00, Ben Schwartz wrote:
>
>
> On Sat, Mar 26, 2022 at 8:32 PM Michael Richardson 
> <[e-mail] <mailto:[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
>
> _______________________________________________
> OPSAWG mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/opsawg