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

Erik Sy <sy@informatik.uni-hamburg.de> Tue, 03 September 2019 21:32 UTC

Return-Path: <sy@informatik.uni-hamburg.de>
X-Original-To: resolverless-dns@ietfa.amsl.com
Delivered-To: resolverless-dns@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D8E112002E for <resolverless-dns@ietfa.amsl.com>; Tue, 3 Sep 2019 14:32:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.199
X-Spam-Level:
X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Uy1r5HY4VMSC for <resolverless-dns@ietfa.amsl.com>; Tue, 3 Sep 2019 14:32:18 -0700 (PDT)
Received: from mailhost.informatik.uni-hamburg.de (mailhost.informatik.uni-hamburg.de [134.100.9.70]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 01CAB1200B6 for <resolverless-dns@ietf.org>; Tue, 3 Sep 2019 14:32:17 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mailhost.informatik.uni-hamburg.de (Postfix) with ESMTP id 1D372C71 for <resolverless-dns@ietf.org>; Tue, 3 Sep 2019 23:32:16 +0200 (CEST)
X-Virus-Scanned: amavisd-new at informatik.uni-hamburg.de
Received: from mailhost.informatik.uni-hamburg.de ([127.0.0.1]) by localhost (mailhost.informatik.uni-hamburg.de [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 9nb7gREyfk2d for <resolverless-dns@ietf.org>; Tue, 3 Sep 2019 23:32:15 +0200 (CEST)
Received: from rzvpn26.informatik.uni-hamburg.de (rzvpn26.informatik.uni-hamburg.de [134.100.4.26]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "Erik Sy", Issuer "DFN-Verein Global Issuing CA" (verified OK)) (Authenticated sender: sy) by mailhost.informatik.uni-hamburg.de (Postfix) with ESMTPSA id D08B8C70 for <resolverless-dns@ietf.org>; Tue, 3 Sep 2019 23:32:14 +0200 (CEST)
From: Erik Sy <sy@informatik.uni-hamburg.de>
To: resolverless-dns@ietf.org
References: <220061a8-608c-0a87-4656-213c87979284@informatik.uni-hamburg.de> <849BE7D4-A07E-496B-B413-E1C979390DA8@osterweil.net> <b2b3e56a-c577-f08a-627a-f54e2e6fadb6@informatik.uni-hamburg.de> <f093a605-6e7d-0237-df5c-441d6789c66f@erik-sy.de> <54892F22-27E4-4444-9CC8-2D9E84A9668F@dukhovni.org> <4ec7dd1d-e914-0adb-4240-296f2f762b5f@informatik.uni-hamburg.de> <ADC6E119-0EED-4990-A975-F594C9282872@dukhovni.org> <64650d58-924f-c0f3-d181-614d59527477@informatik.uni-hamburg.de> <20190830053023.GE90696@straasha.imrryr.org> <f81ec73d-879e-0427-e11b-0973e01034c3@informatik.uni-hamburg.de> <20190902213241.GI70599@straasha.imrryr.org>
Autocrypt: addr=sy@informatik.uni-hamburg.de; prefer-encrypt=mutual; keydata= mQINBFzVyS4BEADnUWBPWNK8CNxDj8QarMioEQsyEiLkpsln4zxw1cxhTnK+ZHd4wTOh1BZf GVmGZ7wdb/NLiQbENv44okX4mYgJjt32gbVg8ssfScfTEO9PVBgLi5SDtLAxLk8TjF7ETIkG NUWgAQm6Pw6EowjLjMJ4y3fahPcypqtfuO1cxF86pPYAsSG+9iuInpBQoZwuvZu3SLUMXB9l +Xwiy77wEpvPg49pNQhbFqlIZXAHTLyEIlrxG41xXbTt7P5kH333c1cRD//EeC2oEjZhgCBh B4ObFpgL4JxSo71MZFdSDOWfiwMq3kXOwJnPNq9xzcWEItVyLK30fXWt5uZ3YfUcZGpGXv1Y Kl4monIru9NFVSW35FlhHtpgUKdQBKJMeuc1ckZr00zRtd1tf/69rdnjJngR+5RJZE3ykDx4 bJ4P75nqeDUe8adc4S0GeExEgsjVl8QZpCgIrjicA4MQERJKaA3bmCWy5YfCqsZYfbFXrcmq sZopkMTI2X5ZsA3y+jjWlmfDo3Tdu9ddfF8BSB0nTbaPLnJCs878T8HE+Lx9y6QyHlfZ0BJx IuepITZInhbH2c/X5Ipw37+YjNCwzlCOozJDZ/tTj8suMpAKdt4qq3OR1PKyhlilUBiQcYDu 4HfGffihD91Bwxz89YsAtej6EvWLjSfF4fUucFMh9N4GSVQK/QARAQABtCZFcmlrIFN5IDxz eUBpbmZvcm1hdGlrLnVpbi1oYW1idXJnLmRlPokCVgQTAQoAQQIbAwUJB4YfgAULCQgHAwUV CgkICwUWAgMBAAIeAQIXgBYhBADP3q0kgaL0XCmyn7pmQSEb9ifsBQJc1dhqAhkBAAoJELpm QSEb9ifs580P9AiLD49H+bZhNwXZYAXD236D6mKBimXo7EnM8D+v6TXiBKweH35XkKjkHtfU nosHYybfQoV8Rjcdg4lZ8+E/N/7Jk0dcQ6N6gUY1YvMw+t5AiEXMZdz6tQEjwrU+FVlBMN7j WKDpumE4PjkKlxh4IPc9HCgmI0G3uq859nIBvHEpPyCc6z1++9zq+oqP8vUtFLqmuAhQJoOc JSyKv7FYnGhGRnGJGPwkdqwGfS6fZaavhKDXgBcvULXKF7gThZp6kAHG7QhEeNmwL4l/UTOA oAu1pwTfelMwkRWwXyZjgnSqY59ejD6lcFdxZ51O4qIfPmxViaORhNcguD9SvdGw6kdEGNIA az+bd8UfVltz2EkWb+KPbDi6bpa12Zr2Sz+8AakDRhEQ6gSLHicK1cyimhsf66i4SjlUMefX Gq2ImH2xJTMSZi2GN/0JtK/KaBfwArvxoNlWfp3aP97fmXeqNWZVJo2T0+Vvr3hKs00XhU/S 82sbVeFmAJMho5SL4GO+CYEYBQUuIUj131JBfgw3o/YB/WuTD+ELuM+VKP0loXPcgfE4UlEM Ik8yJmzKbRRXfwhCpvoc5T0GFtmQ9szMO9cnll+BiDK3qHNtfMsY09PgjCHnOzwhvYMf7H+3 g0dH3HyIY5Id1YPS88GANpqiG+K1d3vwr2dTER5ZUBuu+pq5Ag0EXNXJLgEQAKRNM1sPfiLC nEVME84YDsek0M+5svW6T1ggJL4dAgUdwYyujSrDdEujBr1AJaVHuJzMKLvqAIQqSvid0qVM zH32rx70LIkaLJE6iGbf/ckHHA1bpgzDRY9dcLj/J/B0F94BFx1oSavnP6uD1qRODnc4c9rZ s/GfmdnTxaC84MG26SWua2ckk81+ZP2qenXnebz1Krv0oRvObGW3QzAAjyg7Fdlb9UqRApmI FbM8xtTtNyls+ISruC8KbYTxv5wPegm817iLox9WpXkkJNbM6I/Nn887yvxsZghbiuoJaqJl OQqkm1wlMroQEIVIfZbe9+iSB7wc9KisxAOxsoFTfOeIwNfgH6HMvzNo+yffLnvjNO3v/Yzx utfP4FL00lVl53aTWj+Hq6Bym1EX+ZSSb+LhDW5MzXig4PYJKgZf2L+fr2SfDoiZMY6Nbirt DMAS2TpKaV4Jgc8576qkhwhG7o9GKPmNWV55lo+sFsGIXCsVB5zWjCq/FUJLg+dE+FR6aIR7 q2npur4rz9os69POEbTcIKn3vfbQ8ytaTuRfFGeTq2VjHXzi/qH49+i5sWLgvZug31f0dDhs PKDFdSTKrv2DFaKW9OsAbPoqqT3krqE0ho8iMbOaPqpEUn8z+cR7Ozuz3BE/ZedetOh/W8Kx K04rYuWGo4bZmf42QoKfWM6vABEBAAGJAjwEGAEKACYWIQQAz96tJIGi9Fwpsp+6ZkEhG/Yn 7AUCXNXJLgIbDAUJB4YfgAAKCRC6ZkEhG/Yn7HwtD/98u7M3mR5ktzk2aCkS7grO7PMbEFqS 0ycCOV+3P3u6gMy0conDgywA+niXVmzO4UsD2u7ncE8Y27Gc+nx0Q0MgmZ7Nju/rlLc/xisU Q++0MLhvwWQU6NRIO9hhaPK8gQzkvTtxRWxKljh7fDqlb9L02rCJ5jZ7zpRxGrRanQxkB7Z6 StY2AAaI6SMH6RDV45J2uVT+Fg5qenA3wqgxeY/V2avEFNHMwbs1v3pUmnPo5KTLvaMbMDaf PKu8akQezpO4CK3ugxV3tMQ43RFT4kdl1XQyaKEffLQUyoUyFHGJfq66+01t4cMu4/CEC7D+ S7pkOn7ANuwgilfINHVZ95Z1HOdadMYvt1Q37qmOaK34K6kHLbTglBIb2eBEp/OcUlOcrFEu 7yq1TU6QSvGA9QZVeAfttyA9YqEawB3j11uJm3xMknqS3SzTE0JxZNyz1Qri6OLnP3uVaXJj BCiiGZf6sgnCa7/JlYrrEIF3ukWQutUfG+1XVq85/gPYnmTlenp4PCIuQVJT+ldG3hPNS1un qX0iEGiV8XdwXy9Gg49QAhNOFn6llW17VP279NvEVa6eRAm5w4mp4L3FgpbFlKkCHZXzMx/7 wuYPd9pj+olW2uDid279lKsUGt0I7MVyad311Fd1WnQQrAuEw6ZduDNZMxnhRV4x0PxwnGEY Ye+WbA==
Reply-To: sy@informatik.uni-hamburg.de
Message-ID: <88cef6e4-73bd-7324-8509-a1acbd77750e@informatik.uni-hamburg.de>
Date: Tue, 3 Sep 2019 23:32:12 +0200
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:68.0) Gecko/20100101 Thunderbird/68.0
MIME-Version: 1.0
In-Reply-To: <20190902213241.GI70599@straasha.imrryr.org>
Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="X4pGyAT8xfPq8qhjEOTpOK9oCELsXK8kQ"
Archived-At: <https://mailarchive.ietf.org/arch/msg/resolverless-dns/uz0mNpWMI4-93A2YCB04rSpqI5U>
Subject: Re: [Resolverless-dns] Paper on Resolver-less DNS
X-BeenThere: resolverless-dns@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Resolverless DNS <resolverless-dns.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/resolverless-dns>, <mailto:resolverless-dns-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/resolverless-dns/>
List-Post: <mailto:resolverless-dns@ietf.org>
List-Help: <mailto:resolverless-dns-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/resolverless-dns>, <mailto:resolverless-dns-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 03 Sep 2019 21:32:22 -0000

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