Re: [musl] mDNS in musl

[Jeffrey Walton <noloader@gmail.com>]

On Fri, Mar 8, 2024 at 5:54 PM Rich Felker <dalias@libc.org> wrote:
>
> On Fri, Mar 08, 2024 at 01:55:18PM -0800, David Schinazi wrote:
> > On Fri, Mar 8, 2024 at 12:31 PM 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 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.
> > >
> > > 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 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 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 by 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.
>
> 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), 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.

One comment about pinning. I think host key pinning is a great
security control. Key continuity is a better security property than
key rotation.

Unfortunately, the CA/Browser Forum and IETF are moving the other way.
They are hostile to pinning, they are actively working against it by
using short-lived intermediate CA certificates, by not providing key
rollover hints in existing certificates, and recommending a new key
for each end-entity (host) certificate.

I was very disappointed to see the IETF get onboard with the
CA/Browser Forum. It looks like the IETF has been captured again.

So pinning may not be a viable solution when the time comes.

Jeff