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

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:
>
> 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 
>> <mcr+ietf@sandelman.ca <mailto:mcr%2Bietf@sandelman.ca>> 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
>> OPSAWG@ietf.org
>> https://www.ietf.org/mailman/listinfo/opsawg
>
> _______________________________________________
> OPSAWG mailing list
> OPSAWG@ietf.org
> https://www.ietf.org/mailman/listinfo/opsawg