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 41922216C7 for ; Thu, 21 Mar 2024 14:50:47 +0100 (CET) Received: (qmail 3324 invoked by uid 550); 21 Mar 2024 13:46:12 -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 3285 invoked from network); 21 Mar 2024 13:46:11 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1711029034; x=1711633834; 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=Ma6tgSMpotCaLtFMx3bySnKGidZ+arCfskNKHMdIALc=; b=BBMWpp4/iwShovPktd08q8qNXY5XUNK+cr7Bg/GDlpAKz+DPvNK990r3Dmb2n64WUL bpSpDEaPRWAAoL1tR+VKLkhN6hatP4EgrdZ2VdRgHJx4MARtesdqa6cK9kmp47UifmSo 73rWGdqs/DP/Om1DSlrVES+3jHnnnIWz0vDno5WmxtTJPtN42/yf6uM1UN6LlLjkBkxL 2LC+SQf6wDbEmaRMFYGZ3kb2lSLIYrHuPbKZoSuCDG0zanoziqVZBGMlTNvXfuH7jNRo zVREA2eY1RRBbWFN+UlJqM8aZZdaWxe2g16nEmuxlsOK8JIZA3YrsNSJQ2fnWkqmAyui 12Xg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1711029034; x=1711633834; 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=Ma6tgSMpotCaLtFMx3bySnKGidZ+arCfskNKHMdIALc=; b=ihbt02H/Zev7ZUXfKr8NlDN4GJmXXuKY8YJaYD/C67ilo52PBYSuF9xB2G3A6url3+ PKORt9BqDGB4ftlTvzCZTM2I5O1v575hB7v/8gCoLjfnVz4RSctUdETdId6hTJotl9W9 VfS1krZ5AWbCqXfDkWLJqMTigDDJjxxR1NuuD1bM2dK6CRh3a95G78zku/B3TrZ++clC jd/tzncdOUPJUOPPVtDBfKaNC9SdZiXbuhFHBxg2+b3XyedBh0SuWr8ZAK3QrlaE8mqc lHnvQm7ziwvOG6K/l+nrHh5MFizO3ptmR+L0IIhrSvDUPDI/5phVYUZSDApjLKERBtc8 GSyQ== X-Gm-Message-State: AOJu0Yxl9JilUcLQyH3k3eT/krh4yxEyDZa8NJW7RX5ZkWUJjMq8DCRd O8hfNpPqm5LuRYwEfl5a3J5dvUHXT/EKF7z5iSrW57hlbceXiPz3nYp8DskZ6nm7lppbeM8Nc57 4B+HVb+NvglNmiTLPcAQtUIXDj5zQNkzo231+6Q== X-Google-Smtp-Source: AGHT+IHwRN9gZjrDdgtfJ0agVeBiOtXDx5/67noFF3RE8FCensnAVvlnUKwnxiJl4An0JtfG+i51+Rt5gEL/KK3OePM= X-Received: by 2002:a05:6512:291:b0:513:d030:f313 with SMTP id j17-20020a056512029100b00513d030f313mr1903009lfp.32.1711029033831; Thu, 21 Mar 2024 06:50:33 -0700 (PDT) MIME-Version: 1.0 References: <20240308034740.GL4163@brightrain.aerifal.cx> <20240308133102.GN4163@brightrain.aerifal.cx> <20240308203143.GQ4163@brightrain.aerifal.cx> <20240308225445.GR4163@brightrain.aerifal.cx> <20240321120727.GI15722@brightrain.aerifal.cx> In-Reply-To: <20240321120727.GI15722@brightrain.aerifal.cx> From: David Schinazi Date: Thu, 21 Mar 2024 23:50:21 +1000 Message-ID: To: Rich Felker Cc: musl@lists.openwall.com Content-Type: multipart/alternative; boundary="000000000000c312c306142bfd13" Subject: Re: [musl] mDNS in musl --000000000000c312c306142bfd13 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable My apologies, it wasn't clear to me that these options had been formally rejected, 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 in 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. 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 wrot= e: > 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 option 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 the > > 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 doe= s > 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 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 unless the connected > 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 of > 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 potential > > >> > > 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-p2p > > >> 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 doi= ng > > >> 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 increased information leakage in t= he > > >> default > > >> > > > > configuration and inability to control where the traffic goe= s > > >> when you > > >> > > > > do want it on. The above proposal just reverts to the initia= l, > > >> 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 network > (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 and DN= S > 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 old > 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 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 certificate store. The feature= s > I > > >> > mentioned above don't use the WebPKI, they have a separate root of > > >> trust. > > >> > For example, some of those Apple features exchange TLS certificate= s > 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 using > 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 b= y > DHCP > > >> > then that server can reply with its own address 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 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-compatible > > >> 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 communicat= e > > > with. But they're built knowing that unencrypted HTTP is unsafe. For > > > example, one of my servers doesn't have any authentication - my brows= er > > > 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 information. > Another > > > of my servers uses TLS with self-signed certs, so every time I want t= o > > > 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 wi= ll > > > 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 authenticating > > >> this kind of usage with certificates (probably certificate pinning o= n > > >> 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 the > > > untrusted network can't even hijack the first connection without havi= ng > > > access to that code. The leading one for home automation is Matter [1= ]. > > > Coincidentally, it also leverages mDNS for discovery, and doesn't rel= y > 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 threat > 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 on 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 telling th= e > 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 over > > > 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 othe= r > > > 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 mDN= S > and > > >> > > regular > > >> > > > unicast DNS. As an example, all Apple devices have mDNS enable= d > on > > >> all > > >> > > > interfaces, with no security impact - the features that rely o= n > it > > >> > > > (AirDrop, AirPlay, contact sharing, etc) all use mTLS to ensur= e > > >> they're > > >> > > > talking to the right device regardless of the correctness of > DNS. > > >> > > (Printing > > >> > > > remains completely insecure, but that's also independent of DN= S > - > > >> 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 require= s > 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, an= d > > >> > > 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 chain > 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 you > wrote > > >> is > > >> > only true if the client does the DNSSEC validation itself. Most > 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 great > blog > > >> post > > >> > about this: > > >> > > >> The consensus of folks in the stub resolver space (at least glibc+mu= sl > > >> and I would assume the BSDs as well) is that the way 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 would not be able t= o > > >> 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 device > 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 DNSSEC wa= s > 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 d= o > > >> 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 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 t= o > 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 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 be 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 setup > > >> resolv.conf > > >> > > > > such that .local queries temp-fail rather than perma-fail (a= s > they > > >> > > > > would if you just sent the query to public dns) to use durin= g > > >> 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 localhost. > But the > > >> > > > RFC-compliant answer is for stub resolvers to treat it special= ly > > >> and know > > >> > > > that those often never get an answer (musl doesn't cache DNS > > >> 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 which > 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 sam= e > as a > > >> > resolution failure and will automatically refresh 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, synchronous blocking API= s > 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 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 disable mDNS when th= e > > > resolver is on localhost. I still agree that from an ergonomics > > > perspective, using configs to mean multiple things isn'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 unsecur= ed > > > 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 b= y > 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. Bu= t > > > again, your points about least surprise are still valid, so if you > object > > > to that on those grounds I can't disagree. > > > > > > David > > > > --000000000000c312c306142bfd13 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
My apologies, it wasn't clear to me that these options= had been formally rejected, I'm not familiar with the musl process. Un= fortunately, the choice of off-by-default doesn't follow the relevant s= tandards and, more importantly for me, doesn't solve the use case that = got me interested in working on this. Your choice is reasonable, and I resp= ect it, but given that it no longer solves an issue for=C2=A0me, I won'= t be able to spend time writing code for this. If you do end up moving forw= ard with mDNS, I'm happy to help answer any questions about the mDNS sp= ecifications if you find that helpful.

Best of luck, and= thank you for all the work you do.
David

On Thu, Mar 21, 20= 24 at 10:07=E2=80=AFPM Rich Felker <d= alias@libc.org> wrote:
On Thu, Mar 21, 2024 at 07:21:05PM +1000, David Schinazi wrot= e:
> Hi,
>
> Earlier today at IETF, I discussed this topic with Stuart Cheshire, th= e
> creator of mDNS. From his perspective, implementing a simpler option i= n
> musl makes a lot of sense. Even though querying mDNS on a single inter= face
> is not comprehensive, it'll work for the majority of uses while mi= nimizing
> 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 reasonable secu= rity
> properties. He recommends using the IP_MULTICAST_IF / IPV6_MULTICAST_I= F
> socket options to select an interface, as that's what mDNSResponde= r does on
> Linux. Additionally, he feels strongly that this should be enabled by<= br> > default, since the whole point of zero-configuration networking was fo= r
> 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 connect= ed 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 unless the conn= ected
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 of<= br> 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 <dschinazi.ie= tf@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 Schinazi wrot= e:
> >> > On Fri, Mar 8, 2024 at 12:31=E2=80=AFPM Rich Felker <= dalias@libc.org>= ; wrote:
> >> >
> >> > > On Fri, Mar 08, 2024 at 11:15:52AM -0800, David Sch= inazi wrote:
> >> > > > On Fri, Mar 8, 2024 at 5:30=E2=80=AFAM Rich Fe= lker <dalias@libc.o= rg> wrote:
> >> > > >
> >> > > > > On Thu, Mar 07, 2024 at 08:47:20PM -0800,= David Schinazi wrote:
> >> > > > > > Thanks. How would you feel about the= following potential
> >> > > configuration
> >> > > > > > design?
> >> > > > > > * Add a new configuration option &qu= ot;send_mdns_unicast"
> >> > > > > > * When true, use the current behavio= r
> >> > > > > > * When false, send the query on all = non-loopback non-p2p
> >> interfaces
> >> > > > > > * Have send_mdns_unicast default to = false
> >> > > > > >
> >> > > > > > I was thinking through how to pick i= nterfaces, looked up what
> >> other
> >> > > mDNS
> >> > > > > > libraries do, and pretty much all of= them don't allow
> >> configuring
> >> > > > > > interfaces, whereas Avahi exposes al= low-interfaces and
> >> > > deny-interfaces.
> >> > > > > I'm
> >> > > > > > leaning towards not making this conf= igurable to reduce
> >> complexity. I
> >> > > > > think
> >> > > > > > that anyone interested in that level= of config is probably using
> >> > > Avahi
> >> > > > > > anyway.
> >> > > > > >
> >> > > > > > Additionally this design has two nic= e 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 biggest
> >> problems I
> >> > > > > initially brought up were increased infor= mation leakage in the
> >> default
> >> > > > > configuration and inability to control wh= ere the traffic goes
> >> when you
> >> > > > > do want it on. The above proposal just re= verts to the initial,
> >> except
> >> > > > > for providing a way to opt-out.
> >> > > > >
> >> > > > > For the most part, mDNS is very much a &q= uot;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 wea= kness 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 o= pen browser tab to
> >> > > > > http://mything.local, and migrate to an un= trusted network (with
> >> your
> >> > > > > laptop, tablet, phone, whatever), now you= r browser will be leaking
> >> > > > > private data (likely at least session aut= h tokens, maybe more) to
> >> > > > > whoever answers the mDNS query for mythin= g.local.
> >> > > >
> >> > > > That's not quite right. The security prope= rties of mDNS and DNS are
> >> the
> >> > > > same. DNS is inherently insecure, regardless o= f unicast vs
> >> multicast. If
> >> > > > I'm on a coffee shop Wi-Fi, all my DNS que= ries are sent in the
> >> clear to
> >> > > > whatever IP address the DHCP server gave me. > >> > >
> >> > > That's not the case. Connections to non-mDNS ho= sts are authenticated
> >> > > by TLS with certificates issued on the basis of own= ership of the
> >> > > domain name. That's not possible with mDNS host= names, so they'll
> >> > > either be no-TLS or self-signed certs. That's w= hy the above attack is
> >> > > possible. It was also possible with normal DNS in t= he bad old days of
> >> > > http://, but that time is long gone.
> >> >
> >> > Apologies for being pedantic, but that's not true. T= he ability to get
> >> TLS
> >> > certificates for a domain name that you own is a propert= y 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 certificate store. T= he features I
> >> > mentioned above don't use the WebPKI, they have a se= parate root of
> >> trust.
> >> > For example, some of those Apple features exchange TLS c= ertificates via
> >> an
> >> > out-of-band mechanism such as Apple trusted servers. Ano= ther 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 wa= nts 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 protec= ts the exchange.
> >> > It's resilient to any attacks at the mDNS level.
> >> >
> >> > You're absolutely right that the security of Web req= uests using local
> >> > connectivity is completely broken by the lack of WebPKI = certificates for
> >> > those. But sending the DNS query over multicast as oppos= ed to
> >> unencrypted
> >> > unicast to an untrusted DNS server doesn't change th= e 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 rece= ive your auth
> >> > tokens. One potential fix here is to configure your reso= lv.conf to
> >> > localhost and then apply policy in that local resolver. = But in practice,
> >> > application developers don't rely on security at tha= t 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 abse= nce of a
> >> specific software ecosystem like Apple's. Since we're= talking about
> >> musl which would be running on Linux or a Linux-syscall-compa= tible
> >> 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 commun= icate
> > with. But they're built knowing that unencrypted HTTP is unsa= fe. 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 in= formation. Another
> > of my servers uses TLS with self-signed certs, so every time I wa= nt to
> > communicate with it, I need to click through my browser's &qu= ot;this is 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 authentic= ating
> >> this kind of usage with certificates (probably certificate pi= nning on
> >> first use, with good UX, is the only easy solution),
> >
> >
> > Trust on first use works, or even better there are emerging solut= ions that
> > leverage codes printed on devices and PAKEs so that a device on t= he
> > untrusted network can't even hijack the first connection with= out having
> > access to that code. The leading one for home automation is Matte= r [1].
> > Coincidentally, it also leverages mDNS for discovery, and doesn&#= 39;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 som= eone on
> > the coffee shop Wi-Fi trying to steal your bank credentials. Conv= ersely,
> > it's safe for me to print to this coffee shop printer if my t= hreat 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 te= lling 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 po= tentially
> > 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 probl= em. But my
> > point is that this security problem needs to be solved at the app= lication
> > 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 d= ecided to
> > rely on DNS being secure.
> >
> > In terms of the tradeoff between usability and security, the defa= ult to me
> > lies with default-enabling mDNS on all interfaces as Apple and Av= ahi do.
> > But this tradeoff is between two metrics that can't be quanti= fied 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 p= revent you from
> >> accessing a
> >> > > > TLS service, but can't impersonate it. Tha= t'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 feat= ures that rely on it
> >> > > > (AirDrop, AirPlay, contact sharing, etc) all u= se mTLS to ensure
> >> they're
> >> > > > talking to the right device regardless of the = correctness of DNS.
> >> > > (Printing
> >> > > > remains completely insecure, but that's al= so independent of 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, bu= t it doesn't. DNSSEC
> >> was
> >> > > > unfortunately built with a fundamental design = flaw: it requires you
> >> to
> >> > > > trust all resolvers on the path, including rec= ursive resolvers. So
> >> even
> >> > > if
> >> > > > you ask for DNSSEC validation of the DNS recor= ds for
> >> www.example.com,
> >> > > your
> >> > > > coffee shop DNS recursive resolver can tell yo= u "I checked, and
> >> > > example.com
> >> > > > does not support DNSSEC, here's the IP add= ress for www.example.com
> >> > > though"
> >> > > > and you have to accept it.
> >> > >
> >> > > This is a completely false but somehow persistent m= yth 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 sign= ature chain from
> >> > > the DNS root proving the nonexistence of the DS rec= ords for the
> >> > > delegation. Without that, the reply is BOGUS and wi= ll be ignored as if
> >> > > there was no reply at all.
> >> >
> >> > I was talking about the case where the recursive resolve= r does the
> >> > validation, which is what's deployed in practice tod= ay. What you wrote
> >> is
> >> > only true if the client does the DNSSEC validation itsel= f. Most clients
> >> > don't do that today, because too many domains are ju= st misconfigured and
> >> > broken. Eric Rescorla (the editor of the TLS RFCs) wrote= a great blog
> >> post
> >> > about this:
> >>
> >> The consensus of folks in the stub resolver space (at least g= libc+musl
> >> and I would assume the BSDs as well) is that the way you do D= NSSEC
> >> validation is by having a validating caching proxy or full re= cursive
> >> 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 d= evice as a whole,
> > and by "recursive resolver" I meant "the DNS serve= r 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 validati= on itself".
> > Sorry for being unclear.
> >
> >
> >> This is one of the
> >> reasons our go-to response for new functionality wanted in th= e 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 D= NSSEC was a
> > requirement.
> >
> > It really did not sound like you were talking about trusting the<= br> > >> recursive, though. You called it a "fundamental design f= law", 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 immediat= e
> >> resolver you are interacting with (and not even that if you p= ut the
> >> validation in the stub resolver, but there are good reasons n= ot to do
> >> that, as above). A pure-proxying server that relies on upstre= am
> >> recursives can do full DNSSEC validation. Dnsmasq is a canoni= cal
> >> example. I believe systemd-resolvd also does it.
> >>
> >
> > That's fair, and I apologize for overstating my point. I abso= lutely agree
> > that if you run a validating recursive resolver locally, then the= attack I
> > described isn't possible. When DNSSEC was designed, it was in= tended 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 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 t= hat do
> > things differently.
> >
> > > > > Regarding untrusted networks, one thing I hadn'= ;t considered yet is
> >> > > > > that a network configurator probably need= s a way to setup
> >> resolv.conf
> >> > > > > such that .local queries temp-fail rather= than perma-fail (as they
> >> > > > > would if you just sent the query to publi= c dns) to use during
> >> certain
> >> > > > > race windows while switching networks. IO= W "send .local queries to
> >> > > > > configured nameservers" and "tr= eat .local specially but with an
> >> empty
> >> > > > > list of interfaces to send to" shoul= d be distinct configurations..
> >> > > >
> >> > > > Yeah, caching negative results in DNS has been= a tricky thing from
> >> the
> >> > > > start. You probably could hack something by in= stalling a fake SOA
> >> record
> >> > > > for .local. in your recursive resolver running= on localhost. But the
> >> > > > RFC-compliant answer is for stub resolvers to = treat it specially
> >> and know
> >> > > > that those often never get an answer (musl doe= sn't cache DNS
> >> results so
> >> > > in
> >> > > > a way we're avoiding this problem altogeth= er at the stub resolver)..
> >> > >
> >> > > The problem here is not about caching, just about c= lients using a
> >> > > response. You want a task (like a browser with open= tabs) trying to
> >> > > contact the site to get a tempfail rather than NxDo= main which might
> >> > > make it stop trying. But you probably want NxDomain= if mDNS has been
> >> > > disabled entirely, so that every .local lookup does= n't hang 5 seconds
> >> > > or whatever before saying "inconclusive".=
> >> >
> >> > I'm assuming that by tempfail you mean EAI_AGAIN. Th= e 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 ta= b on a network
> >> > change; Safari doesn't use getaddrinfo and instead r= elies on an
> >> > asynchronous DNS API that adds results as they come in -= I wrote that
> >> > algorithm up in RFC 8305). All that said, synchronous bl= ocking APIs like
> >> > getaddrinfo need to eventually return even if no one rep= lies, 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 t= hem well,
> >> returning EAI_AGAIN vs EAI_NONAME is meaningful and enables t= hem 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 grea= t. 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-loopb= ack
> > interface, the current status quo is to send the .local query uns= ecured
> > 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 sys= tem. In
> > practice there is a slight difference where now you can be attack= ed by any
> > device on the network as opposed to only by the router on that ne= twork, but
> > I'd argue that there's no meaningful threat model that di= stinguishes
> > 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
> >
--000000000000c312c306142bfd13--