From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-2.9 required=5.0 tests=DKIM_ADSP_CUSTOM_MED, DKIM_INVALID,DKIM_SIGNED,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,HTML_MESSAGE,MAILING_LIST_MULTI, RCVD_IN_DNSWL_MED,RCVD_IN_MSPIKE_H4,RCVD_IN_MSPIKE_WL, T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.4 Received: from second.openwall.net (second.openwall.net [193.110.157.125]) by inbox.vuxu.org (Postfix) with SMTP id A616522037 for ; Fri, 22 Mar 2024 01:10:55 +0100 (CET) Received: (qmail 9887 invoked by uid 550); 22 Mar 2024 00:06:19 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Reply-To: musl@lists.openwall.com Received: (qmail 9835 invoked from network); 22 Mar 2024 00:06:18 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1711066242; x=1711671042; darn=lists.openwall.com; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=FwxXwlaZgbudk59WPvJrcL2JW2JOW47G3iA9UF5280o=; b=Ec7R48sydZdadAyPb9454WCqU7xUl+sKwBMo6/1ynCnGCPkIX3X1V6lHq6wKE60OZC 92IxwR1xiwkvf5VMPXmnbvPMMHzWiLiYFiIzTYFNE5ahkWTx1vT+GzaSdSXxPxWJi67w 6m1+JrWb81/l1wEQE1SG2PW9uIL5SWkbYa9ZueJfOzx+P3H7xdi4d7onGjjdYStmMOzM ijdTZpvOQnGQyIAmM4hI3m1n7b2L2owHWW3BwDADwLnTo2xtg1cpTsbFjcq2eQvBYccr QA6w+wFir8rqmR5jjT3D4Azs2XUONQygofHd/EZnX1prmkKRQMa9GA0xZxl1oqDDkKNa mOyQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1711066242; x=1711671042; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=FwxXwlaZgbudk59WPvJrcL2JW2JOW47G3iA9UF5280o=; b=IQvF4C0ifyoF9sV6HK+b+zJL3kmUs9E+YOxPNMdAg6OCsxQsGp8T/g6t6CRvAkbiex s5eAwy34m1fw0St4+W5a20TZY//iFHsALP++HHILp8RiiKK3hVVUbrYWw8Y49gQ1ZEQR FQNhkcU9eqskAyaL0aiv8gEWQs1NaiFHCiznCUnizBu4hTJ1FlqFiLa7ZRtRN1d1552O L0n7nuZY2WhQ5VavE/BhQRRQ+jnBpGLtMLSYqQFrV5fYbKr7O22z5PYX0fDuhHIh3Y+z vHoO+344iCWYkOb+FkwFQKD3FkSl/yKPQO2OrbSZpd89J/UNnODyJ9V/CkFUAj3ThcOT lPzQ== X-Gm-Message-State: AOJu0YyEEPtNn4BNiSTKtPGp+A+uuDnJ4CVjkprmbUBQzEwshn4qpIU9 +RFTtyDh2rMPyWuGC0PTlOph/rhVHDK0eK77P38ojwXN5LHT/m6caRgWPrRhQuX/a1oo//mq/Kk RL2YV01OTrPXgTLZ0htZlotANWPvfhv/c2d3dsni6 X-Google-Smtp-Source: AGHT+IFflqnFFWhF7tnv5zQkuK/9prw1+2ZbBVTVB4OPQU6Z42qdAWj5F0vqHQKQKXXXk2+D8bxB5jGPrpMi3dZbbmM= X-Received: by 2002:ac2:5e23:0:b0:513:2f96:72b5 with SMTP id o3-20020ac25e23000000b005132f9672b5mr603770lfg.33.1711066241497; Thu, 21 Mar 2024 17:10:41 -0700 (PDT) MIME-Version: 1.0 References: <20240308133102.GN4163@brightrain.aerifal.cx> <20240308203143.GQ4163@brightrain.aerifal.cx> <20240308225445.GR4163@brightrain.aerifal.cx> <20240321120727.GI15722@brightrain.aerifal.cx> <20240321193552.GO4163@brightrain.aerifal.cx> In-Reply-To: <20240321193552.GO4163@brightrain.aerifal.cx> From: David Schinazi Date: Fri, 22 Mar 2024 10:10:29 +1000 Message-ID: To: Rich Felker Cc: musl@lists.openwall.com Content-Type: multipart/alternative; boundary="0000000000008306a7061434a7d5" Subject: Re: [musl] mDNS in musl --0000000000008306a7061434a7d5 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Fri, Mar 22, 2024 at 3:46=E2=80=AFAM Luca Barbato w= rote: > > Keep in mind that distributions do and will change the default behavior > of software components as they see fit anyway so if your use-case is > having a desktop oriented distribution using musl support mDNS out of > box, having the feature default off in musl would not make impossible > having the distro default having it on. > That's a good point. My use case is a docker container with Alpine Linux. It has a single interface and /etc/resolv.conf contains a single DNS name server on the local network. lu > > PS: which are the stakeholders contacted while the relevant standards > brought in such hazardous default? These RFCs went through the IETF Standards Track process, so the entire IETF community was consulted when this was finalized around 2011-2012. I'd like to understand why you think this is hazardous though. mDNS only applies to host names under .local - those names are not covered by DNSSEC, and therefore any queries for them are always sent completely insecure. Sending those queries over the wire to the configured DNS resolver has very similar security properties to sending them over the wire as multicast. On Fri, Mar 22, 2024 at 5:35=E2=80=AFAM Rich Felker wrote= : > On Thu, Mar 21, 2024 at 11:50:21PM +1000, David Schinazi wrote: > > My apologies, it wasn't clear to me that these options had been formall= y > > rejected, > > I don't like to use harsh words like "rejected", but from the > beginning my part in this conversation has been about what properties > an mDNS implementation for musl's stub resolver would need to have as > preconditions to make it acceptable for inclusion. My hope was that, > out of bringing the topic to the IETF meeting, we'd have some ideas > for recommended forms for the necessary configuration controls that > might be suitable for multiple implementations to adopt and aid in > interoperability, not for you to come back using it as an > appeal-to-authority to disregard the issues already raised. > My apologies, this wasn't intended as an appeal to authority. And to highlight what I mentioned in my previous email, if you have unique deployment constraints it's perfectly reasonable to do other things like change default behavior. I was confirming what the specifications say - you don't have to follow them. I wasn't trying to disregard the previous points, please see my emails from March 9 that discuss security and threat models. I think the preconditions you've laid out stem from a view of the security properties of DNS that don't match my understanding. We're operating with different assumptions and I don't think we've reached a point of understanding where the difference lies. > I'm not familiar with the musl process. Unfortunately, the choice > > of off-by-default doesn't follow the relevant standards and, more > > importantly for me, doesn't solve the use case that got me interested i= n > > Along with what Luca noted, the relevant standards are about how a > system behaves, not about the mechanisms of a particular part of that > system. > Not really, no. RFC 6762 Section 22.1 paragraph 3 applies to "Name resolution APIs and libraries", not to operating systems. But to be clear it's a SHOULD, so not doing anything is not in violation of the spec per se= . > working on this. Your choice is reasonable, and I respect it, but given > > that it no longer solves an issue for me, I won't be able to spend time > > writing code for this. If you do end up moving forward with mDNS, I'm > happy > > to help answer any questions about the mDNS specifications if you find > that > > helpful. > > That's fine. I'm not in any hurry to make decisions or write code > here, but I'd still be happy to hear from others who want this to > happen for fleshing out whether it makes sense and if so, how the > configuration should work. > > > > > Best of luck, and thank you for all the work you do. > > David > > > > On Thu, Mar 21, 2024 at 10:07=E2=80=AFPM Rich Felker = wrote: > > > > > On Thu, Mar 21, 2024 at 07:21:05PM +1000, David Schinazi wrote: > > > > Hi, > > > > > > > > Earlier today at IETF, I discussed this topic with Stuart Cheshire, > the > > > > creator of mDNS. From his perspective, implementing a simpler optio= n > in > > > > musl makes a lot of sense. Even though querying mDNS on a single > > > interface > > > > is not comprehensive, it'll work for the majority of uses while > > > minimizing > > > > implementation complexity. Using the UDP connect() trick to find th= e > > > > interface corresponding to the configured resolver and then sending > > > > multicast only on that interface will work and provide reasonable > > > security > > > > properties. He recommends using the IP_MULTICAST_IF / > IPV6_MULTICAST_IF > > > > socket options to select an interface, as that's what mDNSResponder > does > > > on > > > > Linux. Additionally, he feels strongly that this should be enabled = by > > > > default, since the whole point of zero-configuration networking was > for > > > > things to work without requiring user configuration. > > > > > > Again, most of these choices are *not workable*. They have already > > > been rejected. > > > > > > If you want this to happen, let's please work on something that has > > > not been rejected. > > > > > > 1. Why on-by-default was rejected: > > > > > > musl is not only or even mostly used in a desktop user configuration > > > where mDNS makes sense. It's used in lots of places where silently > > > starting (after upgrade) to query other devices on a network and > > > accepting answers from them is unexpected and hostile behavior. Yes, > > > "on by default" makes sense on an end-user desktop system connected t= o > > > a *private* network. This would be a default of the particular OS > > > using musl and its network configurator, not of musl itself. (And > > > AFAIK mDNS is not even "on my default" on Windows unless the connecte= d > > > network is marked as private.) > > > > > > 2. Why deciding what network to query based on the interface of the > > > configured resolver is rejected: > > > > > > In a proper DNSSEC-validating setup, the configured resolver is > > > 127.0.0.1 or ::1. This would disable mDNS entirely, forcing you to > > > essentially *switch DNSSEC off if you want mDNS*. It was already > > > explained why this is very bad. > > > > > > Single-interface query has not been rejected, but I don't see any > > > reason to limit mDNS to a single interface. That doesn't make it > > > particularly simpler or anything. If you're able to select the > > > interface, it's just as easy to allow selecting a reasonable number o= f > > > interfaces. > > > > > > The particular implementation mechanisms we've discussed, including > > > possibly identifying the interface(s) to send to via where a > > > particular address would be routed, seem overall good. > > > > > > > > > > On Sat, Mar 9, 2024 at 9:44=E2=80=AFAM David Schinazi > > .com> > > > > wrote: > > > > > > > > > > > > > > > > > > > On Fri, Mar 8, 2024 at 2:54=E2=80=AFPM Rich Felker > wrote: > > > > > > > > > >> On Fri, Mar 08, 2024 at 01:55:18PM -0800, David Schinazi wrote: > > > > >> > On Fri, Mar 8, 2024 at 12:31=E2=80=AFPM Rich Felker > > > wrote: > > > > >> > > > > > >> > > On Fri, Mar 08, 2024 at 11:15:52AM -0800, David Schinazi > wrote: > > > > >> > > > On Fri, Mar 8, 2024 at 5:30=E2=80=AFAM Rich Felker > > > > wrote: > > > > >> > > > > > > > >> > > > > On Thu, Mar 07, 2024 at 08:47:20PM -0800, David Schinazi > > > wrote: > > > > >> > > > > > Thanks. How would you feel about the following potenti= al > > > > >> > > configuration > > > > >> > > > > > design? > > > > >> > > > > > * Add a new configuration option "send_mdns_unicast" > > > > >> > > > > > * When true, use the current behavior > > > > >> > > > > > * When false, send the query on all non-loopback non-p= 2p > > > > >> interfaces > > > > >> > > > > > * Have send_mdns_unicast default to false > > > > >> > > > > > > > > > >> > > > > > I was thinking through how to pick interfaces, looked = up > > > what > > > > >> other > > > > >> > > mDNS > > > > >> > > > > > libraries do, and pretty much all of them don't allow > > > > >> configuring > > > > >> > > > > > interfaces, whereas Avahi exposes allow-interfaces and > > > > >> > > deny-interfaces. > > > > >> > > > > I'm > > > > >> > > > > > leaning towards not making this configurable to reduce > > > > >> complexity. I > > > > >> > > > > think > > > > >> > > > > > that anyone interested in that level of config is > probably > > > using > > > > >> > > Avahi > > > > >> > > > > > anyway. > > > > >> > > > > > > > > > >> > > > > > Additionally this design has two nice properties: the > > > default > > > > >> > > behavior is > > > > >> > > > > > RFC-compliant, and it means that for my use-case I don= 't > > > need to > > > > >> > > change > > > > >> > > > > the > > > > >> > > > > > config file, which was a big part of my motivation for > doing > > > > >> this > > > > >> > > inside > > > > >> > > > > of > > > > >> > > > > > musl in the first place :-) > > > > >> > > > > > > > > >> > > > > As discussed in this thread, I don't think so. The bigge= st > > > > >> problems I > > > > >> > > > > initially brought up were increased information leakage > in the > > > > >> default > > > > >> > > > > configuration and inability to control where the traffic > goes > > > > >> when you > > > > >> > > > > do want it on. The above proposal just reverts to the > initial, > > > > >> except > > > > >> > > > > for providing a way to opt-out. > > > > >> > > > > > > > > >> > > > > For the most part, mDNS is very much a "home user, > personal > > > > >> device on > > > > >> > > > > trusted network" thing. Not only do you not want it to > > > default on > > > > >> > > > > because a lot of systems will be network servers on > networks > > > where > > > > >> > > > > it's not meaningful (and can be a weakness that aids > > > attackers in > > > > >> > > > > lateral movement), but you also don't want it on when > > > connected to > > > > >> > > > > public wifi. For example if you have an open browser tab > to > > > > >> > > > > http://mything.local, and migrate to an untrusted networ= k > > > (with > > > > >> your > > > > >> > > > > laptop, tablet, phone, whatever), now your browser will = be > > > leaking > > > > >> > > > > private data (likely at least session auth tokens, maybe > > > more) to > > > > >> > > > > whoever answers the mDNS query for mything.local. > > > > >> > > > > > > > >> > > > That's not quite right. The security properties of mDNS an= d > DNS > > > are > > > > >> the > > > > >> > > > same. DNS is inherently insecure, regardless of unicast vs > > > > >> multicast. If > > > > >> > > > I'm on a coffee shop Wi-Fi, all my DNS queries are sent in > the > > > > >> clear to > > > > >> > > > whatever IP address the DHCP server gave me. > > > > >> > > > > > > >> > > That's not the case. Connections to non-mDNS hosts are > > > authenticated > > > > >> > > by TLS with certificates issued on the basis of ownership of > the > > > > >> > > domain name. That's not possible with mDNS hostnames, so > they'll > > > > >> > > either be no-TLS or self-signed certs. That's why the above > > > attack is > > > > >> > > possible. It was also possible with normal DNS in the bad ol= d > > > days of > > > > >> > > http://, but that time is long gone. > > > > >> > > > > > >> > Apologies for being pedantic, but that's not true. The ability > to > > > get > > > > >> TLS > > > > >> > certificates for a domain name that you own is a property of t= he > > > WebPKI, > > > > >> > not a property of TLS. What you wrote is true, but only in the > > > context > > > > >> of a > > > > >> > Web browser with an unmodified root certificate store. The > features > > > I > > > > >> > mentioned above don't use the WebPKI, they have a separate roo= t > of > > > > >> trust. > > > > >> > For example, some of those Apple features exchange TLS > certificates > > > via > > > > >> an > > > > >> > out-of-band mechanism such as Apple trusted servers. Another > > > example is > > > > >> the > > > > >> > Apple Watch: when you first pair a new Apple Watch with an > iPhone, > > > they > > > > >> > exchange ed25519 public keys. Then any time the watch wants to > > > transfer > > > > >> a > > > > >> > large file to/from the phone, it'll connect to Wi-Fi, use mDNS > to > > > find > > > > >> the > > > > >> > phone, and set up an IKEv2/IPsec tunnel that then protects the > > > exchange. > > > > >> > It's resilient to any attacks at the mDNS level. > > > > >> > > > > > >> > You're absolutely right that the security of Web requests usin= g > > > local > > > > >> > connectivity is completely broken by the lack of WebPKI > > > certificates for > > > > >> > those. But sending the DNS query over multicast as opposed to > > > > >> unencrypted > > > > >> > unicast to an untrusted DNS server doesn't change the security > > > > >> properties. > > > > >> > In your example above, the open tab to http://mything.local > will > > > send > > > > >> that > > > > >> > query to the recursive resolver - and if that's the one > received by > > > DHCP > > > > >> > then that server can reply with its own address and receive yo= ur > > > auth > > > > >> > tokens. One potential fix here is to configure your resolv.con= f > to > > > > >> > localhost and then apply policy in that local resolver. But in > > > practice, > > > > >> > application developers don't rely on security at that layer, > they > > > assume > > > > >> > that DNS is unsafe and implement encryption in userspace with > some > > > out > > > > >> of > > > > >> > band trust mechanism. > > > > >> > > > > >> My specific example was http://mything.local in a web browser, > which > > > > >> is the way you access lots of mDNS-enabled things in the absence > of a > > > > >> specific software ecosystem like Apple's. Since we're talking > about > > > > >> musl which would be running on Linux or a Linux-syscall-compatib= le > > > > >> environment, without Apple apps, I think that's the main way > anyone > > > > >> would be using hypothetical mDNS support. And indeed this is the > way > > > > >> you access many printers, 3D printers, IP cameras, etc. > > > > >> > > > > > > > > > > I have multiple services at home that use HTTP and mDNS to > communicate > > > > > with. But they're built knowing that unencrypted HTTP is unsafe. > For > > > > > example, one of my servers doesn't have any authentication - my > browser > > > > > just uses unauthenticated GETs, POSTs and WebSockets. If I leave > the > > > tab > > > > > open and go to a coffee shop, my browser might send that GET to a > > > server I > > > > > don't trust but that request won't carry any sensitive informatio= n. > > > Another > > > > > of my servers uses TLS with self-signed certs, so every time I > want to > > > > > communicate with it, I need to click through my browser's "this i= s > > > unsafe" > > > > > interstitial to get to the page. If I switch networks, the browse= r > will > > > > > send me the warning again and I'll know not to click through when > I'm > > > not > > > > > at home. In both of those cases, the security is handled (or not > > > handled at > > > > > all) at the application layer. > > > > > > > > > > Maybe at some point we'll have a good framework for authenticatin= g > > > > >> this kind of usage with certificates (probably certificate > pinning on > > > > >> first use, with good UX, is the only easy solution), > > > > > > > > > > > > > > > Trust on first use works, or even better there are emerging > solutions > > > that > > > > > leverage codes printed on devices and PAKEs so that a device on t= he > > > > > untrusted network can't even hijack the first connection without > having > > > > > access to that code. The leading one for home automation is Matte= r > [1]. > > > > > Coincidentally, it also leverages mDNS for discovery, and doesn't > rely > > > on > > > > > security at the DNS level. > > > > > > > > > > [1] https://csa-iot.org/all-solutions/matter/ > > > > > > > > > > but at present, > > > > >> mDNS devices on the .local zone get accessed with plain http:// > all > > > > >> the time, and this means it's unsafe to do mDNS on > > > > >> public/untrusted/hostile networks. > > > > >> > > > > > > > > > > The notion of something being "unsafe" (and security in general) = is > > > > > predicated on the existence of a threat model. It's unsafe to use > > > > > unencrypted HTTP to your bank when your threat model includes > someone > > > on > > > > > the coffee shop Wi-Fi trying to steal your bank credentials. > > > Conversely, > > > > > it's safe for me to print to this coffee shop printer if my threa= t > > > model > > > > > assumes that I'm ok with the owner of the coffee shop seeing my > > > document. > > > > > Another example is Chromecast which also uses mDNS: from Chrome o= n > a > > > Linux > > > > > laptop, I can cast YouTube videos to the TV in this coffee shop. > That's > > > > > safe because I trust the network with the YouTube link I'm tellin= g > the > > > TV > > > > > to play. mDNS is not in and of itself safe or unsafe. It converts > > > > > names into addresses, and what you do with those addresses can > > > potentially > > > > > be unsafe. > > > > > > > > > > That doesn't mean that every single use of mDNS on untrusted > networks > > > is > > > > > safe. If someone builds a web page that sends valuable secrets ov= er > > > > > unencrypted HTTP to a .local name, then you have a security > problem. > > > But my > > > > > point is that this security problem needs to be solved at the > > > application > > > > > layer and not at the DNS layer. That said, I agree that having a > way to > > > > > disable mDNS on a machine is a good idea, because there probably > are > > > users > > > > > out there that are stuck with applications that for some reason > > > decided to > > > > > rely on DNS being secure. > > > > > > > > > > In terms of the tradeoff between usability and security, the > default > > > to me > > > > > lies with default-enabling mDNS on all interfaces as Apple and > Avahi > > > do. > > > > > But this tradeoff is between two metrics that can't be quantified > one > > > > > against the other for all possible uses, so I totally understand = if > > > your > > > > > opinion for musl is that the tradeoff there is different than in > other > > > > > situations. You know your users better than I do. > > > > > > > > > > > > So the stack has to deal with > > > > >> > > > the fact that any DNS response can be spoofed. > > > > >> > > > > > > >> > > That's also not possible with DNSSEC, but only helps if you'= re > > > > >> > > validating it. > > > > >> > > > > > > >> > > > The most widely used > > > > >> > > > solution is TLS: a successful DNS hijack can prevent you > from > > > > >> accessing a > > > > >> > > > TLS service, but can't impersonate it. That's true of both > mDNS > > > and > > > > >> > > regular > > > > >> > > > unicast DNS. As an example, all Apple devices have mDNS > enabled > > > on > > > > >> all > > > > >> > > > interfaces, with no security impact - the features that > rely on > > > it > > > > >> > > > (AirDrop, AirPlay, contact sharing, etc) all use mTLS to > ensure > > > > >> they're > > > > >> > > > talking to the right device regardless of the correctness = of > > > DNS. > > > > >> > > (Printing > > > > >> > > > remains completely insecure, but that's also independent o= f > DNS > > > - > > > > >> your > > > > >> > > > coffee shop Wi-Fi access point can attack you at the IP > layer > > > too).. > > > > >> One > > > > >> > > > might think that DNSSEC could save us here, but it doesn't= . > > > DNSSEC > > > > >> was > > > > >> > > > unfortunately built with a fundamental design flaw: it > requires > > > you > > > > >> to > > > > >> > > > trust all resolvers on the path, including recursive > resolvers.. > > > So > > > > >> even > > > > >> > > if > > > > >> > > > you ask for DNSSEC validation of the DNS records for > > > > >> www.example.com, > > > > >> > > your > > > > >> > > > coffee shop DNS recursive resolver can tell you "I checked= , > and > > > > >> > > example.com > > > > >> > > > does not support DNSSEC, here's the IP address for > > > www.example.com > > > > >> > > though" > > > > >> > > > and you have to accept it. > > > > >> > > > > > > >> > > This is a completely false but somehow persistent myth about > > > DNSSEC. > > > > >> > > You cannot lie that a zone does not support DNSSEC. The only > way > > > to > > > > >> > > claim a zone does not support DNSSEC is with a signature cha= in > > > from > > > > >> > > the DNS root proving the nonexistence of the DS records for > the > > > > >> > > delegation. Without that, the reply is BOGUS and will be > ignored > > > as if > > > > >> > > there was no reply at all. > > > > >> > > > > > >> > I was talking about the case where the recursive resolver does > the > > > > >> > validation, which is what's deployed in practice today. What y= ou > > > wrote > > > > >> is > > > > >> > only true if the client does the DNSSEC validation itself. Mos= t > > > clients > > > > >> > don't do that today, because too many domains are just > > > misconfigured and > > > > >> > broken. Eric Rescorla (the editor of the TLS RFCs) wrote a gre= at > > > blog > > > > >> post > > > > >> > about this: > > > > >> > > > > >> The consensus of folks in the stub resolver space (at least > glibc+musl > > > > >> and I would assume the BSDs as well) is that the way you do DNSS= EC > > > > >> validation is by having a validating caching proxy or full > recursive > > > > >> resolver on localhost. Doing validation in the stub resolver is > not > > > > >> viable because it may be static-linked, where it would not be > able to > > > > >> be updated with new algorithms, root-of-trust, etc. > > > > > > > > > > > > > > > No disagreement there. By "client" I meant the client device as a > > > whole, > > > > > and by "recursive resolver" I meant "the DNS server you got from > DHCP". > > > > > Running a DNSSEC-validating recursive resolver on the client devi= ce > > > falls > > > > > into what I meant by "if the client does the DNSSEC validation > itself". > > > > > Sorry for being unclear. > > > > > > > > > > > > > > >> This is one of the > > > > >> reasons our go-to response for new functionality wanted in the > stub > > > > >> resolver is "do it in a nameserver on localhost" -- because you > > > > >> already need that to do DNSSEC. > > > > >> > > > > > > > > > > That makes sense. I wasn't working with the assumption that DNSSE= C > was > > > a > > > > > requirement. > > > > > > > > > > It really did not sound like you were talking about trusting the > > > > >> recursive, though. You called it a "fundamental design flaw", > which it > > > > >> is not, and said it requires you to "trust all resolvers on the > path", > > > > >> which it does not. It only requires you to trust the immediate > > > > >> resolver you are interacting with (and not even that if you put > the > > > > >> validation in the stub resolver, but there are good reasons not > to do > > > > >> that, as above). A pure-proxying server that relies on upstream > > > > >> recursives can do full DNSSEC validation. Dnsmasq is a canonical > > > > >> example. I believe systemd-resolvd also does it. > > > > >> > > > > > > > > > > That's fair, and I apologize for overstating my point. I absolute= ly > > > agree > > > > > that if you run a validating recursive resolver locally, then the > > > attack I > > > > > described isn't possible. When DNSSEC was designed, it was > intended to > > > be > > > > > deployed in the model I described, where the validating recursive > > > resolver > > > > > is not on-device. And that's how it is still mostly deployed toda= y > > > because > > > > > almost all general-purpose client devices do not validate locally= . > My > > > > > mental model is very focused around consumer devices where folks > buy > > > them > > > > > and use them without ever changing default settings. That might b= e > a > > > > > portion of musl users, but you clearly also have advanced users > that do > > > > > things differently. > > > > > > > > > > > > > Regarding untrusted networks, one thing I hadn't considered > yet > > > is > > > > >> > > > > that a network configurator probably needs a way to setu= p > > > > >> resolv.conf > > > > >> > > > > such that .local queries temp-fail rather than perma-fai= l > (as > > > they > > > > >> > > > > would if you just sent the query to public dns) to use > during > > > > >> certain > > > > >> > > > > race windows while switching networks. IOW "send .local > > > queries to > > > > >> > > > > configured nameservers" and "treat .local specially but > with > > > an > > > > >> empty > > > > >> > > > > list of interfaces to send to" should be distinct > > > configurations.. > > > > >> > > > > > > > >> > > > Yeah, caching negative results in DNS has been a tricky > thing > > > from > > > > >> the > > > > >> > > > start. You probably could hack something by installing a > fake > > > SOA > > > > >> record > > > > >> > > > for .local. in your recursive resolver running on localhos= t. > > > But the > > > > >> > > > RFC-compliant answer is for stub resolvers to treat it > specially > > > > >> and know > > > > >> > > > that those often never get an answer (musl doesn't cache D= NS > > > > >> results so > > > > >> > > in > > > > >> > > > a way we're avoiding this problem altogether at the stub > > > resolver).. > > > > >> > > > > > > >> > > The problem here is not about caching, just about clients > using a > > > > >> > > response. You want a task (like a browser with open tabs) > trying > > > to > > > > >> > > contact the site to get a tempfail rather than NxDomain whic= h > > > might > > > > >> > > make it stop trying. But you probably want NxDomain if mDNS > has > > > been > > > > >> > > disabled entirely, so that every .local lookup doesn't hang = 5 > > > seconds > > > > >> > > or whatever before saying "inconclusive". > > > > >> > > > > > >> > I'm assuming that by tempfail you mean EAI_AGAIN. The two > browsers > > > that > > > > >> > I've written code in don't use that (Chrome just treats it the > same > > > as a > > > > >> > resolution failure and will automatically refresh the tab on a > > > network > > > > >> > change; Safari doesn't use getaddrinfo and instead relies on a= n > > > > >> > asynchronous DNS API that adds results as they come in - I wro= te > > > that > > > > >> > algorithm up in RFC 8305). All that said, synchronous blocking > APIs > > > like > > > > >> > getaddrinfo need to eventually return even if no one replies, = so > > > > >> EAI_AGAIN > > > > >> > makes sense in that case - whereas if .local is blocked by > policy > > > then > > > > >> > immediately returning EAI_NONAME is best. > > > > >> > > > > >> Right. Even if applications don't currently distinguish them wel= l, > > > > >> returning EAI_AGAIN vs EAI_NONAME is meaningful and enables them > to do > > > > >> the right thing. > > > > >> > > > > > > > > > > Agreed. > > > > > > > > > > Thinking back to our discussion about whether to disable mDNS whe= n > the > > > > > resolver is on localhost. I still agree that from an ergonomics > > > > > perspective, using configs to mean multiple things isn't great. B= ut > > > > > focusing just on the security properties for a second: if > resolv.conf > > > is > > > > > configured to an IP address that is routed over a given > non-loopback > > > > > interface, the current status quo is to send the .local query > unsecured > > > > > over that interface. So if we were to, in that specific scenario, > > > instead > > > > > send the query over multicast, but only on that interface - then = we > > > > > wouldn't measurably change the security properties of the system. > In > > > > > practice there is a slight difference where now you can be > attacked by > > > any > > > > > device on the network as opposed to only by the router on that > > > network, but > > > > > I'd argue that there's no meaningful threat model that > distinguishes > > > > > between those two attacks. So that would be a safe default option= . > But > > > > > again, your points about least surprise are still valid, so if yo= u > > > object > > > > > to that on those grounds I can't disagree. > > > > > > > > > > David > > > > > > > > > --0000000000008306a7061434a7d5 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On = Fri, Mar 22, 2024 at 3:46=E2=80=AFAM Luca Barbato <lu_zero@gentoo.org> wrote:

Keep in mind that distributions do and= will change the default behavior
of software components as they see fit= anyway so if your use-case is
having a desktop oriented distribution us= ing musl support mDNS out of
box, having the feature default off in musl= would not make impossible
having the distro default having it on.

That's a good point. My use case is a do= cker container with Alpine Linux. It has a single interface and /etc/resolv= .conf contains a single DNS name server on the local network.
lu

PS: whic= h are the stakeholders contacted while the relevant standards
brought in= such hazardous default?

These RFCs went th= rough the IETF Standards Track process, so the entire IETF community was co= nsulted when this was finalized around=C2=A02011-2012.

=
I'd like to understand why you think this is hazardous though. mDN= S only applies to host names under .local - those names are not covered by = DNSSEC, and therefore any queries for them are always sent completely insec= ure. Sending those queries over the wire to the configured DNS resolver has= very similar security properties to sending them over the wire as multicas= t.

On Fri, Mar 22, 2024 at 5:35=E2=80=AFAM Rich Felker <dalias@libc.org> wrote:
On Thu, Mar 21, 2024 at 11:50:21PM += 1000, David Schinazi wrote:
> My apologies, it wasn't clear to me that these options had been fo= rmally
> rejected,

I don't like to use harsh words like "rejected", but from the=
beginning my part in this conversation has been about what properties
an mDNS implementation for musl's stub resolver would need to have as preconditions to make it acceptable for inclusion. My hope was that,
out of bringing the topic to the IETF meeting, we'd have some ideas
for recommended forms for the necessary configuration controls that
might be suitable for multiple implementations to adopt and aid in
interoperability, not for you to come back using it as an
appeal-to-authority to disregard the issues already raised.

My apologies, this wasn't intended as an appeal to= authority. And to highlight what I mentioned in my previous email, if you = have unique deployment constraints=C2=A0it's perfectly reasonable to do= other things like change default behavior. I was confirming what the speci= fications say - you don't have to follow them. I wasn't trying to d= isregard the previous points, please see my emails from March 9 that discus= s security and threat models. I think the preconditions you've laid out= stem from a view of the security properties of DNS that don't match my= understanding. We're operating with different assumptions and I don= 9;t think we've reached a point of understanding where the difference l= ies.

> I'm not familiar with the musl process. Unfortunately, the choice<= br> > of off-by-default doesn't follow the relevant standards and, more<= br> > importantly for me, doesn't solve the use case that got me interes= ted in

Along with what Luca noted, the relevant standards are about how a
system behaves, not about the mechanisms of a particular part of that
system.

Not really, no. RFC 6762 Sectio= n 22.1 paragraph 3=C2=A0applies to "Name resolution APIs and libraries= ", not to operating systems. But to be clear it's a SHOULD, so not= doing anything is not in violation of the spec per se.

> working on this. Your choice is reasonable, and I respect it, but give= n
> that it no longer solves an issue for me, I won't be able to spend= time
> writing code for this. If you do end up moving forward with mDNS, I= 9;m happy
> to help answer any questions about the mDNS specifications if you find= that
> helpful.

That's fine. I'm not in any hurry to make decisions or write code here, but I'd still be happy to hear from others who want this to
happen for fleshing out whether it makes sense and if so, how the
configuration should work.



> Best of luck, and thank you for all the work you do.
> David
>
> On Thu, Mar 21, 2024 at 10:07=E2=80=AFPM Rich Felker <dalias@libc.org> wrote:
>
> > On Thu, Mar 21, 2024 at 07:21:05PM +1000, David Schinazi wrote: > > > Hi,
> > >
> > > Earlier today at IETF, I discussed this topic with Stuart Ch= eshire, the
> > > creator of mDNS. From his perspective, implementing a simple= r option in
> > > musl makes a lot of sense. Even though querying mDNS on a si= ngle
> > interface
> > > is not comprehensive, it'll work for the majority of use= s while
> > minimizing
> > > implementation complexity. Using the UDP connect() trick to = find the
> > > interface corresponding to the configured resolver and then = sending
> > > multicast only on that interface will work and provide reaso= nable
> > security
> > > properties. He recommends using the IP_MULTICAST_IF / IPV6_M= ULTICAST_IF
> > > socket options to select an interface, as that's what mD= NSResponder does
> > on
> > > Linux. Additionally, he feels strongly that this should be e= nabled by
> > > default, since the whole point of zero-configuration network= ing was for
> > > things to work without requiring user configuration.
> >
> > Again, most of these choices are *not workable*. They have alread= y
> > been rejected.
> >
> > If you want this to happen, let's please work on something th= at has
> > not been rejected.
> >
> > 1. Why on-by-default was rejected:
> >
> > musl is not only or even mostly used in a desktop user configurat= ion
> > where mDNS makes sense. It's used in lots of places where sil= ently
> > starting (after upgrade) to query other devices on a network and<= br> > > accepting answers from them is unexpected and hostile behavior. Y= es,
> > "on by default" makes sense on an end-user desktop syst= em connected to
> > a *private* network. This would be a default of the particular OS=
> > using musl and its network configurator, not of musl itself. (And=
> > AFAIK mDNS is not even "on my default" on Windows unles= s the connected
> > network is marked as private.)
> >
> > 2. Why deciding what network to query based on the interface of t= he
> > configured resolver is rejected:
> >
> > In a proper DNSSEC-validating setup, the configured resolver is > > 127.0.0.1 or ::1. This would disable mDNS entirely, forcing you t= o
> > essentially *switch DNSSEC off if you want mDNS*. It was already<= br> > > explained why this is very bad.
> >
> > Single-interface query has not been rejected, but I don't see= any
> > reason to limit mDNS to a single interface. That doesn't make= it
> > particularly simpler or anything. If you're able to select th= e
> > interface, it's just as easy to allow selecting a reasonable = number of
> > interfaces.
> >
> > The particular implementation mechanisms we've discussed, inc= luding
> > possibly identifying the interface(s) to send to via where a
> > particular address would be routed, seem overall good.
> >
> >
> > > On Sat, Mar 9, 2024 at 9:44=E2=80=AFAM David Schinazi <ds= chinazi.ietf@gmail.
> > .com>
> > > wrote:
> > >
> > > >
> > > >
> > > > On Fri, Mar 8, 2024 at 2:54=E2=80=AFPM Rich Felker <= dalias@libc.org>= ; wrote:
> > > >
> > > >> On Fri, Mar 08, 2024 at 01:55:18PM -0800, David Sch= inazi wrote:
> > > >> > On Fri, Mar 8, 2024 at 12:31=E2=80=AFPM Rich F= elker <dalias@libc.= org>
> > wrote:
> > > >> >
> > > >> > > On Fri, Mar 08, 2024 at 11:15:52AM -0800,= David Schinazi wrote:
> > > >> > > > On Fri, Mar 8, 2024 at 5:30=E2=80=AF= AM Rich Felker <dal= ias@libc.org>
> > wrote:
> > > >> > > >
> > > >> > > > > On Thu, Mar 07, 2024 at 08:47:2= 0PM -0800, David Schinazi
> > wrote:
> > > >> > > > > > Thanks. How would you feel= about the following potential
> > > >> > > configuration
> > > >> > > > > > design?
> > > >> > > > > > * Add a new configuration = option "send_mdns_unicast"
> > > >> > > > > > * When true, use the curre= nt behavior
> > > >> > > > > > * When false, send the que= ry on all non-loopback non-p2p
> > > >> interfaces
> > > >> > > > > > * Have send_mdns_unicast d= efault to false
> > > >> > > > > >
> > > >> > > > > > I was thinking through how= to pick interfaces, looked up
> > what
> > > >> other
> > > >> > > mDNS
> > > >> > > > > > libraries do, and pretty m= uch all of them don't allow
> > > >> configuring
> > > >> > > > > > interfaces, whereas Avahi = exposes allow-interfaces and
> > > >> > > deny-interfaces.
> > > >> > > > > I'm
> > > >> > > > > > leaning towards not making= this configurable to reduce
> > > >> complexity. I
> > > >> > > > > think
> > > >> > > > > > that anyone interested in = that level of config is probably
> > using
> > > >> > > Avahi
> > > >> > > > > > anyway.
> > > >> > > > > >
> > > >> > > > > > Additionally this design h= as two nice properties: the
> > default
> > > >> > > behavior is
> > > >> > > > > > RFC-compliant, and it mean= s that for my use-case I don't
> > need to
> > > >> > > change
> > > >> > > > > the
> > > >> > > > > > config file, which was a b= ig part of my motivation for doing
> > > >> this
> > > >> > > inside
> > > >> > > > > of
> > > >> > > > > > musl in the first place :-= )
> > > >> > > > >
> > > >> > > > > As discussed in this thread, I = don't think so. The biggest
> > > >> problems I
> > > >> > > > > initially brought up were incre= ased information leakage in the
> > > >> default
> > > >> > > > > configuration and inability to = control where the traffic goes
> > > >> when you
> > > >> > > > > do want it on. The above propos= al just reverts to the initial,
> > > >> except
> > > >> > > > > for providing a way to opt-out.=
> > > >> > > > >
> > > >> > > > > For the most part, mDNS is very= much a "home user, personal
> > > >> device on
> > > >> > > > > trusted network" thing. No= t only do you not want it to
> > default on
> > > >> > > > > because a lot of systems will b= e network servers on networks
> > where
> > > >> > > > > it's not meaningful (and ca= n be a weakness that aids
> > attackers in
> > > >> > > > > lateral movement), but you also= don't want it on when
> > connected to
> > > >> > > > > public wifi. For example if you= have an open browser tab to
> > > >> > > > > http://mything.local, and migrat= e to an untrusted network
> > (with
> > > >> your
> > > >> > > > > laptop, tablet, phone, whatever= ), now your browser will be
> > leaking
> > > >> > > > > private data (likely at least s= ession auth tokens, maybe
> > more) to
> > > >> > > > > whoever answers the mDNS query = for mything.local.
> > > >> > > >
> > > >> > > > That's not quite right. The secu= rity properties of mDNS and DNS
> > are
> > > >> the
> > > >> > > > same. DNS is inherently insecure, re= gardless of unicast vs
> > > >> multicast. If
> > > >> > > > I'm on a coffee shop Wi-Fi, all = my DNS queries are sent in the
> > > >> clear to
> > > >> > > > whatever IP address the DHCP server = gave me.
> > > >> > >
> > > >> > > That's not the case. Connections to n= on-mDNS hosts are
> > authenticated
> > > >> > > by TLS with certificates issued on the ba= sis of ownership of the
> > > >> > > domain name. That's not possible with= mDNS hostnames, so they'll
> > > >> > > either be no-TLS or self-signed certs. Th= at's why the above
> > attack is
> > > >> > > possible. It was also possible with norma= l DNS in the bad old
> > days of
> > > >> > > http://, but that time is long gone.
> > > >> >
> > > >> > Apologies for being pedantic, but that's n= ot true. The ability to
> > get
> > > >> TLS
> > > >> > certificates for a domain name that you own is= a property of the
> > WebPKI,
> > > >> > not a property of TLS. What you wrote is true,= but only in the
> > context
> > > >> of a
> > > >> > Web browser with an unmodified root certificat= e store. The features
> > I
> > > >> > mentioned above don't use the WebPKI, they= have a separate root of
> > > >> trust.
> > > >> > For example, some of those Apple features exch= ange TLS certificates
> > via
> > > >> an
> > > >> > out-of-band mechanism such as Apple trusted se= rvers. Another
> > example is
> > > >> the
> > > >> > Apple Watch: when you first pair a new Apple W= atch with an iPhone,
> > they
> > > >> > exchange ed25519 public keys. Then any time th= e watch wants to
> > transfer
> > > >> a
> > > >> > large file to/from the phone, it'll connec= t to Wi-Fi, use mDNS to
> > find
> > > >> the
> > > >> > phone, and set up an IKEv2/IPsec tunnel that t= hen protects the
> > exchange.
> > > >> > It's resilient to any attacks at the mDNS = level.
> > > >> >
> > > >> > You're absolutely right that the security = of Web requests using
> > local
> > > >> > connectivity is completely broken by the lack = of WebPKI
> > certificates for
> > > >> > those. But sending the DNS query over multicas= t as opposed to
> > > >> unencrypted
> > > >> > unicast to an untrusted DNS server doesn't= change the security
> > > >> properties.
> > > >> > In your example above, the open tab to http://mythi= ng.local will
> > send
> > > >> that
> > > >> > query to the recursive resolver - and if that&= #39;s the one received by
> > DHCP
> > > >> > then that server can reply with its own addres= s and receive your
> > auth
> > > >> > tokens. One potential fix here is to configure= your resolv.conf to
> > > >> > localhost and then apply policy in that local = resolver. But in
> > practice,
> > > >> > application developers don't rely on secur= ity at that layer, they
> > assume
> > > >> > that DNS is unsafe and implement encryption in= userspace with some
> > out
> > > >> of
> > > >> > band trust mechanism.
> > > >>
> > > >> My specific example was http://mything.local in a we= b browser, which
> > > >> is the way you access lots of mDNS-enabled things i= n the absence of a
> > > >> specific software ecosystem like Apple's. Since= we're talking about
> > > >> musl which would be running on Linux or a Linux-sys= call-compatible
> > > >> environment, without Apple apps, I think that's= the main way anyone
> > > >> would be using hypothetical mDNS support. And indee= d this is the way
> > > >> you access many printers, 3D printers, IP cameras, = etc.
> > > >>
> > > >
> > > > I have multiple services at home that use HTTP and mDNS= to communicate
> > > > with. But they're built knowing that unencrypted HT= TP is unsafe. For
> > > > example, one of my servers doesn't have any authent= ication - my browser
> > > > just uses unauthenticated GETs, POSTs and WebSockets. I= f I leave the
> > tab
> > > > open and go to a coffee shop, my browser might send tha= t GET to a
> > server I
> > > > don't trust but that request won't carry any se= nsitive information.
> > Another
> > > > of my servers uses TLS with self-signed certs, so every= time I want to
> > > > communicate with it, I need to click through my browser= 's "this is
> > unsafe"
> > > > interstitial to get to the page. If I switch networks, = the browser will
> > > > send me the warning again and I'll know not to clic= k through when I'm
> > not
> > > > at home. In both of those cases, the security is handle= d (or not
> > handled at
> > > > all) at the application layer.
> > > >
> > > > Maybe at some point we'll have a good framework for= authenticating
> > > >> this kind of usage with certificates (probably cert= ificate pinning on
> > > >> first use, with good UX, is the only easy solution)= ,
> > > >
> > > >
> > > > Trust on first use works, or even better there are emer= ging solutions
> > that
> > > > leverage codes printed on devices and PAKEs so that a d= evice on the
> > > > untrusted network can't even hijack the first conne= ction without having
> > > > access to that code. The leading one for home automatio= n is Matter [1].
> > > > Coincidentally, it also leverages mDNS for discovery, a= nd doesn't rely
> > on
> > > > security at the DNS level.
> > > >
> > > > [1] https://csa-iot.org/all-solutions/m= atter/
> > > >
> > > > but at present,
> > > >> mDNS devices on the .local zone get accessed with p= lain http:// all
> > > >> the time, and this means it's unsafe to do mDNS= on
> > > >> public/untrusted/hostile networks.
> > > >>
> > > >
> > > > The notion of something being "unsafe" (and s= ecurity in general) is
> > > > predicated on the existence of a threat model. It's= unsafe to use
> > > > unencrypted HTTP to your bank when your threat model in= cludes someone
> > on
> > > > the coffee shop Wi-Fi trying to steal your bank credent= ials.
> > Conversely,
> > > > it's safe for me to print to this coffee shop print= er if my threat
> > model
> > > > assumes that I'm ok with the owner of the coffee sh= op seeing my
> > document.
> > > > Another example is Chromecast which also uses mDNS: fro= m Chrome on a
> > Linux
> > > > laptop, I can cast YouTube videos to the TV in this cof= fee shop. That's
> > > > safe because I trust the network with the YouTube link = I'm telling the
> > TV
> > > > to play. mDNS is not in and of itself safe or unsafe. I= t converts
> > > > names into addresses, and what you do with those addres= ses can
> > potentially
> > > > be unsafe.
> > > >
> > > > That doesn't mean that every single use of mDNS on = untrusted networks
> > is
> > > > safe. If someone builds a web page that sends valuable = secrets over
> > > > unencrypted HTTP to a .local name, then you have a secu= rity problem.
> > But my
> > > > point is that this security problem needs to be solved = at the
> > application
> > > > layer and not at the DNS layer. That said, I agree that= having a way to
> > > > disable mDNS on a machine is a good idea, because there= probably are
> > users
> > > > out there that are stuck with applications that for som= e reason
> > decided to
> > > > rely on DNS being secure.
> > > >
> > > > In terms of the tradeoff between usability and security= , the default
> > to me
> > > > lies with default-enabling mDNS on all interfaces as Ap= ple and Avahi
> > do.
> > > > But this tradeoff is between two metrics that can't= be quantified one
> > > > against the other for all possible uses, so I totally u= nderstand if
> > your
> > > > opinion for musl is that the tradeoff there is differen= t than in other
> > > > situations. You know your users better than I do.
> > > >
> > > > > > So the stack has to deal with
> > > >> > > > the fact that any DNS response can b= e spoofed.
> > > >> > >
> > > >> > > That's also not possible with DNSSEC,= but only helps if you're
> > > >> > > validating it.
> > > >> > >
> > > >> > > > The most widely used
> > > >> > > > solution is TLS: a successful DNS hi= jack can prevent you from
> > > >> accessing a
> > > >> > > > TLS service, but can't impersona= te it. That's true of both mDNS
> > and
> > > >> > > regular
> > > >> > > > unicast DNS. As an example, all Appl= e devices have mDNS enabled
> > on
> > > >> all
> > > >> > > > interfaces, with no security impact = - the features that rely on
> > it
> > > >> > > > (AirDrop, AirPlay, contact sharing, = etc) all use mTLS to ensure
> > > >> they're
> > > >> > > > talking to the right device regardle= ss of the correctness of
> > DNS.
> > > >> > > (Printing
> > > >> > > > remains completely insecure, but tha= t's also independent of DNS
> > -
> > > >> your
> > > >> > > > coffee shop Wi-Fi access point can a= ttack you at the IP layer
> > too)..
> > > >> One
> > > >> > > > might think that DNSSEC could save u= s here, but it doesn't.
> > DNSSEC
> > > >> was
> > > >> > > > unfortunately built with a fundament= al design flaw: it requires
> > you
> > > >> to
> > > >> > > > trust all resolvers on the path, inc= luding recursive resolvers..
> > So
> > > >> even
> > > >> > > if
> > > >> > > > you ask for DNSSEC validation of the= DNS records for
> > > >> www.example.com,
> > > >> > > your
> > > >> > > > coffee shop DNS recursive resolver c= an tell you "I checked, and
> > > >> > > example.com
> > > >> > > > does not support DNSSEC, here's = the IP address for
> > www.example.com
> > > >> > > though"
> > > >> > > > and you have to accept it.
> > > >> > >
> > > >> > > This is a completely false but somehow pe= rsistent myth about
> > DNSSEC.
> > > >> > > You cannot lie that a zone does not suppo= rt DNSSEC. The only way
> > to
> > > >> > > claim a zone does not support DNSSEC is w= ith a signature chain
> > from
> > > >> > > the DNS root proving the nonexistence of = the DS records for the
> > > >> > > delegation. Without that, the reply is BO= GUS and will be ignored
> > as if
> > > >> > > there was no reply at all.
> > > >> >
> > > >> > I was talking about the case where the recursi= ve resolver does the
> > > >> > validation, which is what's deployed in pr= actice today. What you
> > wrote
> > > >> is
> > > >> > only true if the client does the DNSSEC valida= tion itself. Most
> > clients
> > > >> > don't do that today, because too many doma= ins are just
> > misconfigured and
> > > >> > broken. Eric Rescorla (the editor of the TLS R= FCs) wrote a great
> > blog
> > > >> post
> > > >> > about this:
> > > >>
> > > >> The consensus of folks in the stub resolver space (= at least glibc+musl
> > > >> and I would assume the BSDs as well) is that the wa= y you do DNSSEC
> > > >> validation is by having a validating caching proxy = or full recursive
> > > >> resolver on localhost. Doing validation in the stub= resolver is not
> > > >> viable because it may be static-linked, where it wo= uld not be able to
> > > >> be updated with new algorithms, root-of-trust, etc.=
> > > >
> > > >
> > > > No disagreement there. By "client" I meant th= e client device as a
> > whole,
> > > > and by "recursive resolver" I meant "the= DNS server you got from DHCP".
> > > > Running a DNSSEC-validating recursive resolver on the c= lient device
> > falls
> > > > into what I meant by "if the client does the DNSSE= C validation itself".
> > > > Sorry for being unclear.
> > > >
> > > >
> > > >> This is one of the
> > > >> reasons our go-to response for new functionality wa= nted in the stub
> > > >> resolver is "do it in a nameserver on localhos= t" -- because you
> > > >> already need that to do DNSSEC.
> > > >>
> > > >
> > > > That makes sense. I wasn't working with the assumpt= ion that DNSSEC was
> > a
> > > > requirement.
> > > >
> > > > It really did not sound like you were talking about tru= sting the
> > > >> recursive, though. You called it a "fundamenta= l design flaw", which it
> > > >> is not, and said it requires you to "trust all= resolvers on the path",
> > > >> which it does not. It only requires you to trust th= e immediate
> > > >> resolver you are interacting with (and not even tha= t if you put the
> > > >> validation in the stub resolver, but there are good= reasons not to do
> > > >> that, as above). A pure-proxying server that relies= on upstream
> > > >> recursives can do full DNSSEC validation. Dnsmasq i= s a canonical
> > > >> example. I believe systemd-resolvd also does it. > > > >>
> > > >
> > > > That's fair, and I apologize for overstating my poi= nt. I absolutely
> > agree
> > > > that if you run a validating recursive resolver locally= , then the
> > attack I
> > > > described isn't possible. When DNSSEC was designed,= it was intended to
> > be
> > > > deployed in the model I described, where the validating= recursive
> > resolver
> > > > is not on-device. And that's how it is still mostly= deployed today
> > because
> > > > almost all general-purpose client devices do not valida= te locally. My
> > > > mental model is very focused around consumer devices wh= ere folks buy
> > them
> > > > and use them without ever changing default settings. Th= at might be a
> > > > portion of musl users, but you clearly also have advanc= ed users that do
> > > > things differently.
> > > >
> > > > > > > Regarding untrusted networks, one thing = I hadn't considered yet
> > is
> > > >> > > > > that a network configurator pro= bably needs a way to setup
> > > >> resolv.conf
> > > >> > > > > such that .local queries temp-f= ail rather than perma-fail (as
> > they
> > > >> > > > > would if you just sent the quer= y to public dns) to use during
> > > >> certain
> > > >> > > > > race windows while switching ne= tworks. IOW "send .local
> > queries to
> > > >> > > > > configured nameservers" an= d "treat .local specially but with
> > an
> > > >> empty
> > > >> > > > > list of interfaces to send to&q= uot; should be distinct
> > configurations..
> > > >> > > >
> > > >> > > > Yeah, caching negative results in DN= S has been a tricky thing
> > from
> > > >> the
> > > >> > > > start. You probably could hack somet= hing by installing a fake
> > SOA
> > > >> record
> > > >> > > > for .local. in your recursive resolv= er running on localhost.
> > But the
> > > >> > > > RFC-compliant answer is for stub res= olvers to treat it specially
> > > >> and know
> > > >> > > > that those often never get an answer= (musl doesn't cache DNS
> > > >> results so
> > > >> > > in
> > > >> > > > a way we're avoiding this proble= m altogether at the stub
> > resolver)..
> > > >> > >
> > > >> > > The problem here is not about caching, ju= st about clients using a
> > > >> > > response. You want a task (like a browser= with open tabs) trying
> > to
> > > >> > > contact the site to get a tempfail rather= than NxDomain which
> > might
> > > >> > > make it stop trying. But you probably wan= t NxDomain if mDNS has
> > been
> > > >> > > disabled entirely, so that every .local l= ookup doesn't hang 5
> > seconds
> > > >> > > or whatever before saying "inconclus= ive".
> > > >> >
> > > >> > I'm assuming that by tempfail you mean EAI= _AGAIN. The two browsers
> > that
> > > >> > I've written code in don't use that (C= hrome just treats it the same
> > as a
> > > >> > resolution failure and will automatically refr= esh the tab on a
> > network
> > > >> > change; Safari doesn't use getaddrinfo and= instead relies on an
> > > >> > asynchronous DNS API that adds results as they= come in - I wrote
> > that
> > > >> > algorithm up in RFC 8305). All that said, sync= hronous blocking APIs
> > like
> > > >> > getaddrinfo need to eventually return even if = no one replies, so
> > > >> EAI_AGAIN
> > > >> > makes sense in that case - whereas if .local i= s blocked by policy
> > then
> > > >> > immediately returning EAI_NONAME is best.
> > > >>
> > > >> Right. Even if applications don't currently dis= tinguish them well,
> > > >> returning EAI_AGAIN vs EAI_NONAME is meaningful and= enables them to do
> > > >> the right thing.
> > > >>
> > > >
> > > > Agreed.
> > > >
> > > > Thinking back to our discussion about whether to disabl= e mDNS when the
> > > > resolver is on localhost. I still agree that from an er= gonomics
> > > > perspective, using configs to mean multiple things isn&= #39;t great. But
> > > > focusing just on the security properties for a second: = if resolv.conf
> > is
> > > > configured to an IP address that is routed over a given= non-loopback
> > > > interface, the current status quo is to send the .local= query unsecured
> > > > over that interface. So if we were to, in that specific= scenario,
> > instead
> > > > send the query over multicast, but only on that interfa= ce - then we
> > > > wouldn't measurably change the security properties = of the system. In
> > > > practice there is a slight difference where now you can= be attacked by
> > any
> > > > device on the network as opposed to only by the router = on that
> > network, but
> > > > I'd argue that there's no meaningful threat mod= el that distinguishes
> > > > between those two attacks. So that would be a safe defa= ult option. But
> > > > again, your points about least surprise are still valid= , so if you
> > object
> > > > to that on those grounds I can't disagree.
> > > >
> > > > David
> > > >
> >
--0000000000008306a7061434a7d5--