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

[Viktor Dukhovni <[e-mail]>]

On Mon, Sep 02, 2019 at 10:52:30PM +0200, Erik Sy wrote:

> > 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,
>
> Can you name a popular client doing DNSSEC validation in a web browsing
> scenario?

Any client behind a nearby (local or private network) validating
resolver.

> >  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).
>
> Note, that in resolver-less DNS the client does not trust received DNS
> records like it is common for the traditional DNS. Instead, the client
> validates these DNS records.

No, it validates that the server on the other end of the connection
has the expected certificate, which is rather different from the
actual addresses being valid.

> >>> 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,
>
> Do you mean the client is doing DNSSEC validation?

In most cases the resolver, not the client.  But the server may be
sufficiently local, and it is much easier for attackers to entice
users to visit a hostile site than to perform a off-path cache
poisoning attack.

> > 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.
> 
> Do you mind describing an concrete attack?

The hostile website vends fake IPv6 addresses for domains it does
not control (in an address range it does control) to the browser.
When the user later visits one of the cache poisoned sites, the
connection is tracked.  Further surprising to the user is that
unlike visits to links via the site tracked via redirects, the
target domain need not even be one vended in any link from the
hostile site.  Use of a TTL captures furthe interaction with the
remote site, not just the initial connection.

> It is an easy task for an web server to track user visits to other sites
> by using for example redirects as Google Search is doing.

Resolverless-DNS as proposed makes this far more troubling.  I don't
have to click on Google's tracked links.  But as proposed, a website
can arbitrarily populate my cache for destinations it wants to
monitor (for some time after I've long left the original site, given
that the records have a TTL).

> First, it is quite uncommon that people run their own DNS resolver.

Times change.  Some security-conscious users are starting to use
more secure home routers:

	https://www.turris.cz/en/omnia/

which include a sufficiently local validating resolver, that
communicates with a trusted upstream via DoT.

> Second, running an own DNS resolver generates new privacy and
> performance problems.

FWIW, my validating resolver forwards to (load shares its queries
across) multiple public validating resolvers (Cloudflare, Google,
Verisign and Quad9).  So there are no new privacy issues, just
a reasonable expectation that validation happens sufficiently
close to my browser to make cache poisoning rather difficult.

> >  Your proposal would delegate this ability
> > to every random server I visit.  That's a security fail.
> 
> I do not understand why this should be a security fail. In my opinion it
> is not even an additional privacy failure because the privacy leak
> existed before using common techniques such as redirects.

The scope is much worse, as explained above.

-- 
	Viktor.