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

From: Michael Richardson <[email-masked]>
Date: Sat, 26 Mar 2022 20:32:15 -0400

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.

---

From: Ben Schwartz <[email-masked]>
Date: Mon, 28 Mar 2022 19:00:59 +0000

> 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

---

From: "Independent Submissions Editor (Eliot Lear)" <[email-masked]>
Date: Mon, 28 Mar 2022 21:25:58 +0200

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 
> <[email-masked] <mailto:[email-masked]>> wrote:
>
> transport proxies generally, are the right solution here.  My point is 
> that the MUD gateway architecture described here is fatally flawed. 
> 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.
>
> _______________________________________________
> OPSAWG mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/opsawg

---

From: Eliot Lear <[email-masked]>
Date: Mon, 28 Mar 2022 21:27:44 +0200

My apologies.  This should have gone out under my name, not under that 
of the ISE.  The ISE has no interest in this.

Eliot

On 28.03.22 21:25, Independent Submissions Editor (Eliot Lear) wrote:
> 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.
>
> 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
>
>> 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.
>>
>> 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:
>>
>> 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

---

From: Michael Richardson <[email-masked]>
Date: Mon, 28 Mar 2022 18:18:41 -0400

> implemented in browsers and OSes.

Yeah, that's not going to fly.
  } [1] https://datatracker.ietf.org/doc/html/draft-ietf-wrec-wpad-01 
1) draft-ietf-wrec-wpad is a 22 year old ID which specifies use of a
   private-use DHCP option (252).
   
   While one think one can get away with an SRV entry, that requires
   local DNS to be working, which is exactly the kind of thing that
   IoT manufacturers are having trouble relying upon.
   (Yes, if a MUD controller is present, we can expect local DNS
   to be more reliable, but it is exactly in the opposite case that there is
   concern) 
   
2) Once you find the CFile, according to the URL you dug up 
   (Thank you. The link in the 22 year old ID is long dead)

    > https://developer.mozilla.org/en-US/docs/Web/HTTP/Proxy_servers_and_tunneling/Proxy_Auto-Configuration_PAC_file

The PAC file is javascript?

-- 
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-