Normally, I like to reply with specific changes, but I haven't figured out what changes to make, and I also see that there are some XXX in my document that also reflect places I wanted to also make changes. So, please expect another reply with some specific text, once I've faulted enough pages back into the brain.
David Lamparter via Datatracker <[email protected]> wrote: > 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". I think that I'd like to take another round trip with DNSOP then to make sure that I've covered all the ways, and perhaps there is simply a document that I can reference. > - 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. Yes, I agree that there is vulnerability here. Having the MUD controller do DNSSEC validation helps a lot, if the manufacturer can be bothered to sign with DNSSEC. Or using DoH, DoT... as either way the attacker now has to compromise the authoritative servers. I feel that there is a lot more to say here. > 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. Yes, that certainly can be done, and in the home router (which is also the DNS server for the device), then it occurs quite naturally. Note that the goal of MUD is not perfect mapping, but rather a reduction in risk. As such I want to be very cautious about throwing away incremental improvements because they aren't perfect. > 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? This is already possible. I think that it will lead to too many operational problems. Do you think that the document should deal with this in a pro/con section? > 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. Yes, that's true. As we go towards ESNI, I hope that firewalls won't try to do this, as I think that *validating* SNI is a mistake. Observing and auditing and logging if there are changes is a different situation though. I think it is reasonable for a MUD file to tell the MUD controller if the SNI should be visible or not (see draft-ietf-opsawg-mud-tls...) > 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.) This definitely could be done. www-all.example.com, when www.example.com will return a geo-fenced address. > 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. Agreed. I think that this paragraph is worth integrating into the document somewhere. > 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. Yes, it sure happens. Go read the threads in ADD, particularly from Paul Vixie, about how Google devices will keep trying to talk to 8.8.8.8, even when given a local, fully functional, DNS server via DHCP, and even when 8.8.8.8 is blocked. > 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.) Yes, go read Geoff Houston comments/presentation from the side meetings after IETF112, at RIPE-83, and on the RIPE DNS-WG ML. The short of it is that DNS resolution doesn't make any money for the ISP, having it break costs them money and reputation, and so if they can outsource it to Google, from the ISP's point of view and for many users, it's a win-win. From a MUD controller point of view, it's just fine if the home router talks to some outsourced DNS server rather, as long as the queries from the device get cached in the router. This is exactly how openwrt running dnsmasq work today. > 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. Yeah. Are you asking for strong language here? > 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.) 6.1 is not about MUD exactly, but rather other protocols. Section 4.1 talks about this problem. In my experience trying to fashion MUD files for things like printers, it's endemnic in the update protocol. > 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. May I use your Atlantis/Little Mermaid example? :-) I am of the wrong age to really have experienced that film (too old for me, and it's too ancient to interest my kid... now teenager). I don't remember there being dialysis machines in Atlantica. > 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. Frankly, I hope that they do use MUD. That's the whole point here. If it's not good enough for them, then why are we even bothering? They are currently frantically trying to put ACLs in place to restrict access by devices to the network. The amount of call-home-or-it-does-not-work is quite amazing. Yes, most of here in the IETF think that IoT should be devices talking to other devices, not device->cloud->device, but firewalls and NAT44 have gotten in the way. -- Michael Richardson <[email protected]> . o O ( IPv6 IøT consulting ) Sandelman Software Works Inc, Ottawa and Worldwide
signature.asc
Description: PGP signature
_______________________________________________ OPSAWG mailing list [email protected] https://www.ietf.org/mailman/listinfo/opsawg
