Early Review of draft-ietf-opsawg-mud-iot-dns-considerations-02
review-ietf-opsawg-mud-iot-dns-considerations-02-intdir-early-lamparter-2021-12-19-00

[I've thrown a copy of this on https://gist.github.com/eqvinox/4e3e96f117b059f65e8a449fbb71738f]

Hi Michael and all,


I've been poked for an Early Review of your MUD DNS draft.  Here's what
feedback I have at this point.  (I've looked at the -02 version on the
datatracker, but I don't think you've changed much in your git repo compared
to that.)

re. 3. Strategies to map names
- plain reverse lookups.

Some vendor working with cheapest available developers will sadly understand
your list as "oh I just need to do my reverse maps /right/ and then it should
work."  I'd say "explain in detail how this can fail." is not enough, it might
need to be "explain in detail how this can fail even if the vendor tries its
best".

- the controller doing lookups, (potentially using the same caching resolver)

The MUD controller and the device using the same resolver is a neccssary
requirement, but not a sufficent one.  Worse even, this is essentially a
Time-Of-Check-Time-Of-Use security vulnerability.  An attacker may be able to
distinguish device-originated DNS lookups from controller-originated lookups
and give the controller a much longer list of replies while still allowing the
device to function normally to cover their tracks.  It's fringe (if you can
break DNS like that there's probably better things you can exploit), but still.

I haven't really put extensive thought into this, but the only
pedantically-correct solution to me seems to be to actually track the exact
DNS responses that were given to the device.


re 4.1. Use of IP address literals in-protocol

Nothing says the MUD file and device spec need to specify the target in the
same way.  It might actually be a good idea to give the device a DNS name to
resolve, but just list all the IP addresses in the MUD file.  The vendor should
absolutely be able to do that in some cases at least (i.e. no highly dynamic
changes to the addresses.)  Considering all else, this might even be one of the
better approaches?

On a sidenote, this also means it's wrong for the firewall to try to validate
SNI names when the MUD file only lists IP addresses.

Technically the MUD file could also list a *different* DNS name that is
guaranteed to return a superset of addresses that might be used by the device.
Whether this is a good idea I don't know.  (Also note this conflicts with
monitoring a device's DNS lookups to track the actual responses it received.)

Ultimately though what I'd like to note here is that there's 2 different
objectives here.  The device itself wants a useful subset of addresses to
contact.  But the firewall needs the superset of anything the device might
need to talk to.


re 5. DNS privacy and outsourcing versus MUD controllers

I honestly don't understand how any device vendor can reasonably encode some
specific DNS service into their device and expect it to work.  If my network,
whether it be home or corporate, has a policy for some specific DNS cache to
be used (e.g. on some firewall appliance), a MUD file isn't going to punch a
hole into my policy for that.  And this really zaps all the DoT & DoH bits at
the same time.

And with me being from Germany I can tell you we have ISPs that give their
users a checkbox to block Cloudflare DoH on their service - not even for
technical merits, just because it was a publicity sh*tstorm.  (Nevermind the
fact that the ISPs may have their own ulterior motives.)


re 6. / conclusions in general

I'm not sure how far I should go here with review, I'm not involved in any
discussions here and am probably missing a bunch of context.

6.5. seems a no-brainer, maybe even too weak of a conclusion.  Devices /really/
should use the DNS they get told by the network.

6.1. is the MUD file a protocol too?  It's not clear from the text.

(I do also disagree on the conclusion, in my naive world the vendor should
really be able to list all possible IP addresses for the services, and doing
so is likely the most robust way.  But I'm a "there is no cloud, just other
people's computers" person, so maybe I expect too much of vendors.)


re 7. Privacy and 8. Security:

Posession of intimate devices may cause embarassment.  Posession of personal
healthcare devices may open people up to attacks on their life.  Imagine some
dissident in Atlantis being assassinated on Princess Arielle's orders by way
of targeting something on the dissident's dialysis machine, pacemaker, or
whatever else.

But vendors will still read this as "eh, people won't care if someone has my
devices".  And then 5 years later they get bought up and the new owner makes
sex toys off the same codebase :)

And lastly: "requirements for the devices to get access to network resources
that may be critical to their continued safe operation." ... I guess this is
more of a comment, but I certainly hope no hospital, metalworks, sewage works,
or power plant ever depends on MUD functioning correctly to ensure *safe*
operation.


Hope this is useful input,

-David