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 AA70E22978 for ; Thu, 21 Mar 2024 10:21:32 +0100 (CET) Received: (qmail 1411 invoked by uid 550); 21 Mar 2024 09:16:56 -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 1375 invoked from network); 21 Mar 2024 09:16:56 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1711012878; x=1711617678; 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=8m3f8xg8AOJ7y5oXC5AsNkttkR0Ne/4PpLE9d3e13Ik=; b=d9USbUwZwF1vZJNi+1bCSlC8IjKJnIsqzUaznluygwDiDCyd1Rkcj2hikzImADGyN5 NGQ0gAa6evf13JsOCHjJVHDYb8/W/b5l+iIsJzRyAo+gXE9KLIXGvy6/EIGhsjq2TNuK gOaLHz2CPSWqsvcO4L70/aBZME3Be+WuLoG+6o5H61M4ObOGQd2ZJO9i7c9dPa+yX0Yn KRlO8mXN+OYyjIvMy02PpclDruVEdEADE6zbb+aWt8tQYjWdmNgN7xmceQsYNer8nSvm IYuQT88n97RvBB7ISeNXv5piTYT+XtoPSfjOmwTUz5vDFEXZMk3W7u2fjwiKaTM3fjHN YPQw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1711012878; x=1711617678; 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=8m3f8xg8AOJ7y5oXC5AsNkttkR0Ne/4PpLE9d3e13Ik=; b=BEgiVufJKq07bO2RXTccE6YH0bt6AvpQslZSUhKnFaUWtyJtFMk7dOFMGwCZs+b8ek 1N9bdwYgovnMO/q0dLXxKjz6ClpR1wbFEK0MlWw5Q8muc7dIGm55RPxPaRmGoXbSCvsY 5RdosvPrBIE+rB4LD++6vkgM5nsFqj++abMUvg/Lk+1Zw8/gqveOKeP6Ke4WiVeSp+Qx kRP3wWKraqLDzKLBGHdU7qCTi0Z8+EhIt4QUdwmtRasJdLo1WNEHG3Vc1xBmBO50iqiC IWrcCVnj2odlIG4H1Sn7WnEOL+RCmdK2Kr6QsslrISKe6QSn590vl+Z8Bguf6Y1qngFj X3ww== X-Gm-Message-State: AOJu0YyjKz3Rd//xhH8ctoHJrNW2PcX/5KMS9CayVK/JPrbeyIoQmdSd OE+9zvhXHEsVi4PnJQBumfs6K8mdBhp70rDgGknBViqnfxiVtA5mxsTnV9L5kvxJXyvLyScuLHI NJkzSPvWuZ70ro+la4UV/vwXZBfl7Mgl6cA89vy5u X-Google-Smtp-Source: AGHT+IGWPW2c/w3w3yJJagiOIJzoO+Zq0RAZpguhhmMo9vtk3fOxWLR6bNwq9t7l3C8VsT19LWH7oy/4DytjuX2vd14= X-Received: by 2002:a17:907:b9c9:b0:a47:1547:4cad with SMTP id xa9-20020a170907b9c900b00a4715474cadmr503795ejc.61.1711012877809; Thu, 21 Mar 2024 02:21:17 -0700 (PDT) MIME-Version: 1.0 References: <20240308000818.GJ4163@brightrain.aerifal.cx> <20240308025204.GK4163@brightrain.aerifal.cx> <20240308034740.GL4163@brightrain.aerifal.cx> <20240308133102.GN4163@brightrain.aerifal.cx> <20240308203143.GQ4163@brightrain.aerifal.cx> <20240308225445.GR4163@brightrain.aerifal.cx> In-Reply-To: From: David Schinazi Date: Thu, 21 Mar 2024 19:21:05 +1000 Message-ID: To: Rich Felker Cc: musl@lists.openwall.com Content-Type: multipart/alternative; boundary="000000000000c9c6de0614283af2" Subject: Re: [musl] mDNS in musl --000000000000c9c6de0614283af2 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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 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. Thanks, David On Sat, Mar 9, 2024 at 9:44=E2=80=AFAM David Schinazi wrote: > > > On Fri, Mar 8, 2024 at 2:54=E2=80=AFPM Rich Felker wrot= e: > >> 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 usi= ng >> > > 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 biggest >> 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 o= n >> > > > > because a lot of systems will be network servers on networks whe= re >> > > > > it's not meaningful (and can be a weakness that aids attackers i= n >> > > > > 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 leaki= ng >> > > > > private data (likely at least session auth tokens, maybe more) t= o >> > > > > whoever answers the mDNS query for mything.local. >> > > > >> > > > That's not quite right. The security properties of mDNS and DNS ar= e >> 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 i= s >> > > possible. It was also possible with normal DNS in the bad old days o= f >> > > 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 WebPK= I, >> > 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 root of >> trust. >> > For example, some of those Apple features exchange TLS certificates vi= a >> an >> > out-of-band mechanism such as Apple trusted servers. Another example i= s >> the >> > Apple Watch: when you first pair a new Apple Watch with an iPhone, the= y >> > exchange ed25519 public keys. Then any time the watch wants to transfe= r >> 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 exchang= e. >> > 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 f= or >> > 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 DH= CP >> > 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 practic= e, >> > application developers don't rely on security at that layer, they assu= me >> > 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 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 information. Anoth= er > 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 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 on >> first use, with good UX, is the only easy solution), > > > Trust on first use works, or even better there are emerging solutions tha= t > leverage codes printed on devices and PAKEs so that a device on the > untrusted network can't even hijack the first connection without having > access to that code. The leading one for home automation is Matter [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 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 Linu= x > 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 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 potentiall= y > 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 user= s > out there that are stuck with applications that for some reason decided t= o > rely on DNS being secure. > > In terms of the tradeoff between usability and security, the default to m= e > 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 an= d >> > > 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 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, but it doesn't. DNSSEC >> was >> > > > unfortunately built with a fundamental design flaw: it requires yo= u >> 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 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 client= s >> > don't do that today, because too many domains are just misconfigured a= nd >> > 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+musl >> 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 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 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 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 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 resolve= r > is not on-device. And that's how it is still mostly deployed today becaus= e > 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 (as th= ey >> > > > > 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 localhost. But t= he >> > > > RFC-compliant answer is for stub resolvers 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 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 second= s >> > > or whatever before saying "inconclusive". >> > >> > I'm assuming that by tempfail you mean EAI_AGAIN. The two browsers tha= t >> > 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 an >> > asynchronous DNS API that adds results as they come in - I wrote that >> > algorithm up in RFC 8305). All that said, synchronous blocking APIs li= ke >> > 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 the > 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 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 an= y > device on the network as opposed to only by the router on that network, b= ut > 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 you object > to that on those grounds I can't disagree. > > David > --000000000000c9c6de0614283af2 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
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 qu= erying 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 r= esolver and then sending multicast only on that interface will work and pro= vide reasonable security properties. He recommends using the=C2=A0IP_MULTIC= AST_IF / IPV6_MULTICAST_IF socket options to select an interface, as that&#= 39;s what mDNSResponder does on Linux. Additionally, he feels strongly that= this should be enabled by default, since the whole point of zero-configura= tion networking was for things to work without requiring user configuration= .

Thanks,
David

On Sat, Mar 9, 2024= at 9:44=E2=80=AFAM David Schinazi <dschinazi.ietf@gmail.com> wrote:


On F= ri, Mar 8, 2024 at 2:54=E2=80=AFPM Rich Felker <dalias@libc.org> wrote:
On Fri, Mar 08, 2024 at 01:55:1= 8PM -0800, David Schinazi wrote:
> 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 Schinazi wrote: > > > On Fri, Mar 8, 2024 at 5:30=E2=80=AFAM Rich Felker <dalias@libc.org> wro= te:
> > >
> > > > On Thu, Mar 07, 2024 at 08:47:20PM -0800, David Schinaz= i wrote:
> > > > > Thanks. How would you feel about the following pot= ential
> > configuration
> > > > > design?
> > > > > * Add a new configuration option "send_mdns_u= nicast"
> > > > > * When true, use the current behavior
> > > > > * When false, send the query on all non-loopback n= on-p2p interfaces
> > > > > * Have send_mdns_unicast default to false
> > > > >
> > > > > I was thinking through how to pick interfaces, loo= ked 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 re= duce 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 = biggest problems I
> > > > initially brought up were increased information leakage= in the default
> > > > configuration and inability to control where the traffi= c goes when you
> > > > do want it on. The above proposal just reverts to the i= nitial, 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 i= t to default on
> > > > because a lot of systems will be network servers on net= works where
> > > > it's not meaningful (and can be a weakness that aid= s attackers in
> > > > lateral movement), but you also don't want it on wh= en connected to
> > > > public wifi. For example if you have an open browser ta= b 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, mayb= e more) to
> > > > whoever answers the mDNS query for mything.local.
> > >
> > > That's not quite right. The security properties of mDNS = and DNS are the
> > > same. DNS is inherently insecure, regardless of unicast vs m= ulticast. 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 authen= ticated
> > by TLS with certificates issued on the basis of ownership of the<= br> > > 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 a= ttack is
> > possible. It was also possible with normal DNS in the bad old day= s 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 WebPK= I,
> 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<= br> > mentioned above don't use the WebPKI, they have a separate root of= trust.
> For example, some of those Apple features exchange TLS certificates vi= a an
> out-of-band mechanism such as Apple trusted servers. Another example i= s the
> Apple Watch: when you first pair a new Apple Watch with an iPhone, the= y
> exchange ed25519 public keys. Then any time the watch wants to transfe= r 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 exchang= e.
> It's resilient to any attacks at the mDNS level.
>
> You're absolutely right that the security of Web requests using lo= cal
> connectivity is completely broken by the lack of WebPKI certificates f= or
> those. But sending the DNS query over multicast as opposed to unencryp= ted
> unicast to an untrusted DNS server doesn't change the security pro= perties.
> In your example above, the open tab to http://mything.local will send t= hat
> 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<= br> > tokens. One potential fix here is to configure your resolv.conf to
> localhost and then apply policy in that local resolver. But in practic= e,
> 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= communicate with. But they're built knowing that unencrypted HTTP is u= nsafe. For example, one of my servers doesn't have any authentication -= my browser just uses unauthenticated GETs, POSTs and WebSockets. If I leav= e 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 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 n= etworks, the browser will send me the warning again and I'll know not t= o click through when I'm not at home. In both of those cases, the secur= ity 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 on
first use, with good UX, is the only easy solution),

<= /div>
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=C2=A0first connection withou= t having access to that code. The leading one for home automation is Matter= [1]. Coincidentally, it also leverages mDNS for discovery,=C2=A0and doesn&= #39;t rely on security at the DNS level.


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 p= redicated on the existence of a threat model. It's unsafe to use unencr= ypted HTTP to your bank when your threat model includes someone on the coff= ee shop Wi-Fi trying to steal your bank credentials. Conversely, it's s= afe 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. Anoth= er example is Chromecast which also uses mDNS: from Chrome on a=C2=A0Linux = 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 the= TV to play. mDNS is not in and of itself safe or unsafe. It converts names= =C2=A0into 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 th= at 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 t= o 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,=C2=A0= because there probably are users out there that are stuck with applications= that=C2=A0for some reason decided to rely on DNS being secure.
<= br>
In terms of the tradeoff between usability and security, the = default to me lies with default-enabling mDNS on all interfaces as Apple an= d Avahi do. But this tradeoff is between two metrics that can't be quan= tified 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 o= ther 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&#= 39;re
> > validating it.
> >
> > > The most widely used
> > > solution is TLS: a successful DNS hijack can prevent you fro= m accessing a
> > > TLS service, but can't impersonate it. That's true o= f both mDNS and
> > regular
> > > unicast DNS. As an example, all Apple devices have mDNS enab= led on all
> > > interfaces, with no security impact - the features that rely= on it
> > > (AirDrop, AirPlay, contact sharing, etc) all use mTLS to ens= ure they're
> > > talking to the right device regardless of the correctness of= DNS.
> > (Printing
> > > remains completely insecure, but that's also independent= of DNS - your
> > > coffee shop Wi-Fi access point can attack you at the IP laye= r too). One
> > > might think that DNSSEC could save us here, but it doesn'= ;t. DNSSEC was
> > > unfortunately built with a fundamental design flaw: it requi= res you to
> > > trust all resolvers on the path, including recursive resolve= rs. So even
> > if
> > > you ask for DNSSEC validation of the DNS records for www.exampl= e.com,
> > your
> > > coffee shop DNS recursive resolver can tell you "I chec= ked, and
> > example.com
> > > does not support DNSSEC, here's the IP address for www.exam= ple.com
> > though"
> > > and you have to accept it.
> >
> > This is a completely false but somehow persistent myth about DNSS= EC.
> > 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 fr= om
> > 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 w= rote is
> only true if the client does the DNSSEC validation itself. Most client= s
> don't do that today, because too many domains are just misconfigur= ed 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+musl
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 to
be updated with new algorithms, root-of-trust, etc.

No disagreement there. By "client" I meant the client=C2= =A0device as a whole, and by "recursive resolver" I meant "t= he DNS server you got from DHCP". Running a DNSSEC-validating recursiv= e resolver on the client device falls into what I meant by "if the cli= ent does the DNSSEC validation itself". Sorry for being unclear.
=C2=A0
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 ma= kes sense. I wasn't working with the assumption that DNSSEC was a requi= rement.

It really did not sound like you were talking about trusting the
recursive, though. You called it a "fundamental design flaw", whi= ch it
is not, and said it requires you to "trust all resolvers on the path&q= uot;,
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.

<= /div>
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= intended to be deployed in the model I described, where the validating rec= ursive resolver is not on-device. And that's how it is still mostly dep= loyed today because almost all general-purpose client devices do not valida= te locally. My mental model is very focused around consumer devices where f= olks buy them and use them without ever changing default settings. That mig= ht be a portion of musl users, but you clearly also have advanced users tha= t do things differently.

> > > Regarding untrusted networks, one thing I hadn't conside= red yet is
> > > > that a network configurator probably needs a way to set= up resolv.conf
> > > > such that .local queries temp-fail rather than perma-fa= il (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 spe= cially but with an empty
> > > > list of interfaces to send to" should be distinct = configurations.
> > >
> > > Yeah, caching negative results in DNS has been a tricky thin= g from the
> > > start. You probably could hack something by installing a fak= e SOA record
> > > for .local. in your recursive resolver running on localhost.= But the
> > > RFC-compliant answer is for stub resolvers to treat it speci= ally 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 mig= ht
> > make it stop trying. But you probably want NxDomain if mDNS has b= een
> > 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 an > asynchronous DNS API that adds results as they come in - I wrote that<= br> > algorithm up in RFC 8305). All that said, synchronous blocking APIs li= ke
> getaddrinfo need to eventually return even if no one replies, so EAI_A= GAIN
> 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 wh= en the resolver is on localhost. I still agree that from an ergonomics pers= pective, using configs to mean multiple things isn't great. But focusin= g just on the security properties for a second: if resolv.conf is configure= d 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 interfac= e. 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 ch= ange the security properties of the system. In practice there is a slight d= ifference where now you can be attacked by any device on the network as opp= osed to only by the router on that network, but I'd argue that there= 9;s no meaningful threat model that distinguishes between those two attacks= . So that would be a safe default option. But again, your points about leas= t surprise are still valid, so if you object to that on those grounds I can= 't disagree.

David
--000000000000c9c6de0614283af2--