Re: [Mud] Intdir early review of draft-ietf-opsawg-mud-iot-dns-considerations-02
David Lamparter <equinox@diac24.net> Sat, 25 December 2021 11:09 UTC
Return-Path: <equinox@diac24.net>
X-Original-To: mud@ietfa.amsl.com
Delivered-To: mud@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A35F73A0D43; Sat, 25 Dec 2021 03:09:23 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L8oYC6EKqtu2; Sat, 25 Dec 2021 03:09:18 -0800 (PST)
Received: from eidolon.nox.tf (eidolon.nox.tf [IPv6:2a07:2ec0:2185::]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0E1203A0D42; Sat, 25 Dec 2021 03:09:15 -0800 (PST)
Received: from equinox by eidolon.nox.tf with local (Exim 4.94.2) (envelope-from <equinox@diac24.net>) id 1n14vF-0092VB-6h; Sat, 25 Dec 2021 12:09:09 +0100
Date: Sat, 25 Dec 2021 12:09:09 +0100
From: David Lamparter <equinox@diac24.net>
To: Michael Richardson <mcr+ietf@sandelman.ca>
Cc: int-dir@ietf.org, mud@ietf.org, draft-ietf-opsawg-mud-iot-dns-considerations.all@ietf.org, opsawg@ietf.org
Message-ID: <Ycb71T2OrwI66BLO@eidolon.nox.tf>
References: <163994413394.12070.6171048717943515773@ietfa.amsl.com> <14215.1640371946@localhost>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <14215.1640371946@localhost>
Archived-At: <https://mailarchive.ietf.org/arch/msg/mud/rJtlboH5ZxFckfCgK4mKunUbdLs>
Subject: Re: [Mud] Intdir early review of draft-ietf-opsawg-mud-iot-dns-considerations-02
X-BeenThere: mud@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Discussion of Manufacturer Ussage Descriptions <mud.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mud>, <mailto:mud-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/mud/>
List-Post: <mailto:mud@ietf.org>
List-Help: <mailto:mud-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mud>, <mailto:mud-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 25 Dec 2021 11:09:24 -0000
On Fri, Dec 24, 2021 at 01:52:26PM -0500, Michael Richardson wrote: > 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. I'm noticing I communicated some of my thoughts quite poorly, probably in part because I was somewhat unsure on distinguishing "comments" from "review". Apologies for that, I'll note to put a bit more time into clearer communication on future reviews. I also have really taken a wrong turn in basing some of my feedback on thinking the names looked up by the device would match ACL entries in the MUD file, particularly this first item: > > - 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. In retrospect, I really regret bringing this perspective to the table. It only makes sense from a "100% match/constraint" perspective. But with a make-before-break approach, the ACL being wider than the actual usage by the MUD device is intentional. Turning my paragraph on its head, it might rather be prudent to repeat (for the benefit of network operators) that a MUD file can be arbitrarily lax on its constraints. Attacks on DNS can't widen it further than plain manufacturer indifference to putting work into a good set of ACLs. But after spending a bit more thought on this, I actually think I have a good piece of proper "review" suggestion: I think it would be immensely useful to add/describe the perspective of what happens when addresses associated with a service are 1. added, 2. removed, or 3. fully replaced. All the DNS caching and "perspective" effects come down to the same differences, but they're corner cases to ops. Moving services around is core ops. [-- continued below at anchor "A"] > I feel that there is a lot more to say here. And it really applies generally to using DNS names in ACLs. I'm unaware of any other document that went this direction, is there any? RFC 8520 might've skipped over a seemingly innocuous but on closer look quite nontrivial chunk of considerations 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. [-- anchor "A", continuing on add/remove/replace] Looking at these 3 temporal changes, the takeaway I've evolved to at this point is that there are 2 overall patterns to get to "full correctness": - either the MUD controller shares the exact DNS->IP view that the MUD device has, ideally down to individual DNS lookup results. BUT: this implies the names listed in the MUD file must exactly match what the device looks up - and that's neither provided nor intended by 8520. Which really just renders this moot for further consideration. (It also requires controller and device to use the same DNS infrastructure.) - or the entire thing instead moves to a make-before-break approach. The names in the MUD file receive address additions before the device sees them, and deletions after they expire out of device visibility. BUT: this implies the names listed cannot match what the device looks up/uses, and needs significant extra care by the device manufacturer. The second item here I had kindof headed towards in my original review when I mentioned using separate names, but I'll freely admit I hadn't thought this to the end of being good ol' make-before-break. Both approaches would solve the 3 "temporal operations", though in almost antithetical ways: construct a kind of atomicity to the changes vs. split the operation into 2 or 3 stages. [-- anchor "B", the following 3 paragraphs are redunant, left them here just for clarity/explicitness] Ultimately, again, this is really an issue of diametrically opposed function of the name lookups. Not sure which terms to use - "necessary vs. sufficient", "additive vs. subtractive", "permissive vs. restrictive" - but it boils down to: The MUD device starts with an empty set of endpoints and uses DNS to put a few addresses into the set so it can pick something to talk to. If the set of addresses is *smaller* than the set of addresses that provide the necessary service/function for the device to operate, that's perfectly fine. The MUD controller starts with allowing the unrestricted set of the entire internet (equivalent to no MUD file too) and is using DNS to narrow down this set. If the set of addresses is *larger* than the set id above, that's perfectly fine. [-- end redundant] > 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. Fully agree. Lacking sufficient context and knowledge, I unfortunately have no clue what would lead to the best actual realized improvements. > > 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? This paragraph of mine really came about from me thinking about the make-before-break consideration above, though I hadn't arrived at that myself just yet. I suggested listing all the IP addresses only because I was stuck with this "additive" use of DNS and took listing addresses as "subtractive" converse. The real point is to distinguish that converse approach, not the distinction between use of DNS and addresses. > > 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...) Let me reword the review item: for section 1, SNI considerations, I think you should make clear the MUD file is making no commitment at all that the names listed in the ACLs would match what the device ends up negotiating a TLS connection to. The DNS names in a MUD file are just indirections to listing IP addresses. So looking at SNI names is wrong even when it's possible. > > 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. Exactly this. > > 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. [this is what the earlier 3 paragraphs at anchor "B" are redundant with.] [...some paragraphs cut...] > > 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? Yes, though to clarify, I should've inserted a "first" there. Nothing wrong with a fallback, if it's implemented correctly. (And if a particular network requires DNS lookups from devices to pass through its DNS service to enforce some security purpose, it needs to be blocking other DNS anyway.) > > 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. Ok - this absolutely needs wording clarification, because your current wording can be read as recommendations to either "always use DNS names on the device and MUD file", but also "always use DNS names, but this is no statement about the MUD file". > > 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? :-) Sure :D > 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. Honestly I just didn't want to name any particular oppressive regime for obvious political reasons. I thought about fictional continents and only associated to the movie from there... > > 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. Oh they absolutely should. I was trying to say they can't rely on it for functional safety. In most fields, safety regulations and certifications will already require safe operation to be a property inherent to the device as much as possible. A MUD file is an extra defensive layer, but if it fails open, that's no excuse for a device to die in a "bad" way (e.g. because background internet traffic like SSH portscans tripped/deadlocked something in its embedded firmware, and the deadlock causes e.g. raw sewage to get into the drinking water supply.) Cheers and Happy Holidays, -David
- Re: [Mud] Intdir early review of draft-ietf-opsaw… Michael Richardson
- Re: [Mud] Intdir early review of draft-ietf-opsaw… David Lamparter