Re: [musl] mDNS in musl

[David Schinazi <dschinazi.ietf@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 6039 bytes --]

On Fri, Mar 8, 2024 at 5:30 AM Rich Felker <dalias@libc.org> 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 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 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 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. So the stack has to deal with
the fact that any DNS response can be spoofed. 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 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 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. The world has accepted that DNS can be spoofed,
deployed TLS in applications, and moved on. The important remaining bit was
improving the privacy of DNS, and that was solved by DNS-over-TLS,
DNS-over-HTTPS, and DNS-over-QUIC - all of which don't provide DNS
integrity checking end-to-end but allow you to encrypt your DNS packets
between the client and trusted recursive resolver. Going back to your
example, http://mything.local is only safe on trusted networks regardless
of changes in the DNS stack because the coffee shop router can inspect and
modify your HTTP request and response. The issue here is that unencrypted
http is insecure, not the DNS.

Windows has a setting when you add wifi networks for whether they're
> treated as private/trusted or public. I would guess it controls
> whether mDNS is used, among other things like SMB scanning or
> whatever. The same really belongs in a network configurator for
> Linux-based personal devices.
>
> Fortunately, I think an approach where you opt-in particular
> interfaces/source-addresses, rather than send everywhere by default,
> has lower implementation cost and complexity on top of being the safe
> thing to do. So none of the above should be taken as a "no" for the
> functionality, just a no for "on by default and send everywhere".
>

And that's totally fair. If your argument is that "defaults should reflect
the previous behavior", then I can't argue. That said, I disagree that this
is measurably safer.

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 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 localhost. 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 DNS results so in
a way we're avoiding this problem altogether at the stub resolver).

David

[-- Attachment #2: Type: text/html, Size: 7208 bytes --]