Re: [Resolverless-dns] Paper on Resolver-less DNS

[Viktor Dukhovni <[e-mail]>]

On Thu, Aug 29, 2019 at 11:28:13PM +0200, Erik Sy wrote:

> On 8/29/19 17:34, Viktor Dukhovni wrote:
> > Resolver-less DNS as proposed disregards long-standing defenses
> > against address forgery by third parties,
>
> Can you please explain this point?

IIRC the protocol allows any authenticated server (with Let's
Encrypt, that's everybody) to return "out-of-bailiwick" answers
(for any unrelated domain).

Yes, a client's designated resolver can also do that, but some
clients perform local DNSSEC validation, and in any case there's a
big difference between trusting name resolution to a set of dedicated
resolvers, vs. each and every server one happens to visit (by
clicking on a malicious link for example).

> >  breaks geo load-balancing,
>
> No, there are no new issues with geo load-balancing compared to using a
> public DNS resolver.

Well, the public DNS resolvers (which I do not use on my network)
typically pass an EDNS0 client-subnet option to the upstream
authoritative server.  I don't recall anything similar in the paper.

But if we're doing away with geo load-balancing, and moving to only
using anycast IPs to reduce latency, that's fine by me, there are
other more important problems.

> > breaks local filters that protect networks against known bad actors,
> > and IDS systems that detect compromised nodes.
>
> If you think there are any new issues compared to using a public DNS
> resolver, I would appreciate you explaining these points.

There are a lot more resolvers than the public DNS resolvers that
you seem to expect the whole world to be using.  The resolvers at
the office and on my home network are local, I don't use "public
DNS resolvers".

> > It introduce a new cache-poisoning channel, and surprising differences
> > between the IP addresses a browser might use to reach a site from cold
> > start vs. after visiting some unrelated site.
>
> Also traditional DNS resolvers are vulnerable to cache-poisoning attacks.

Not with DNSSEC validation, and modestly difficult off-path.  But
with this proposal, you get cache poisoing by design from any
off-path server the client happens to visit.

> > In the case of IPv6 it can be used to fingerprint and track clients by
> > giving them ephemeral client-specific addresses (in the server's /64
> > or broader prefix) for third-party servers, and then proxying their
> > connections (at layer 4) to the real server, while tracking the
> > client's access to each site.
>
> This tracking mechanism is also feasible using traditional DNS.

But not available to every off-path server I visit.  My resolver
does not do that.  Your proposal would delegate this ability
to every random server I visit.  That's a security fail.

> >> At least the given mechanism needs also to provide a significant
> >> security benefit. In my view, the additional benefit of DNSSEC+ DANE
> >> compared to Certificate Transparency + Strict Transport Security (HSTS
> >> or MTA-STS) is for the majority of server operators or users not relevant.
> > Let's not mix up HTTP and MTA-to-MTA SMTP.  In SMTP, DANE has significantly
> > broader deployment (protected domains) than MTA-STS.
>
> Please note that MTA-STS is still a very young protocol.

It is not getting much support from either Exim or Postfix, any
time soon it is mostly a cloud-provider <-> cloud-provider walled
garden.  If you like your mail centralized and mined for targetted
ads, use email from these providers and MTA-STS.

But again the issues with resolverless DNS (for web browsers) are
unrelated to DANE vs. MTA-STS for MTA-to-MTA SMTP, or even DANE for
the web.  DANE and PKIX are concerned with peer authentication, not
integrity of IP address records, and modulo traffic analysis provide
a secure channel even if layers 1 through 4 are compromised by the
attacker.

-- 
	Viktor.