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

[Erik Sy <[e-mail]>]

On 9/2/19 23:32, Viktor Dukhovni wrote:
> 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.
It seems like in your described scenario the resolver is doing DNSSEC
validation and not the client.
>>>  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.

Most prominently the DNS resolves domain names into IP addresses. In my
view, a DNS record is certainly valid if I can reach the correct host at
the provided IP address. Note, that DNSSEC allows only to validate the
integrity of the DNS record but not that the IP address is valid for a
given domain name. Resolver-less DNS does not need to trust the
authoritative nameserver because it really validates that a given host
can be reached at the presented IP address.

>>>>> 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.
Note, that the attack is even easier for a hostile DNS resolver because
the user does not need to be enticed to visit a hostile site.
>
>>> 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.

The paper recommends in Section 3.2.2., that browsers should restrict
the context in which they use retrieved DNS records to the same website.
This prevents your described attack. I understand that your described
tracking mechanism is feasible but it is also feasible in a scenario
without resolver-less DNS. Furthermore, learning that the user follows a
provided link has never been very difficult.

>> 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).
Not feasible as explained above.
>
>> 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.

In my view, your described setup is not a traditional self-hosted DNS
resolver. From a privacy perspective, I think that sharing the DNS
lookups across a small number of entities can lead to a situation where
each of these entities may be able to reconstruct a large share of your
online activities.

Erik