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

Bob Harold <rharolde@umich.edu> Wed, 04 September 2019 12:58 UTC

Return-Path: <rharolde@umich.edu>
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 1C2BE1200F9 for <resolverless-dns@ietfa.amsl.com>; Wed, 4 Sep 2019 05:58:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level:
X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=umich.edu
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 R5092DP6VFNU for <resolverless-dns@ietfa.amsl.com>; Wed, 4 Sep 2019 05:58:33 -0700 (PDT)
Received: from mail-lj1-x232.google.com (mail-lj1-x232.google.com [IPv6:2a00:1450:4864:20::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9D86A1200F6 for <resolverless-dns@ietf.org>; Wed, 4 Sep 2019 05:58:32 -0700 (PDT)
Received: by mail-lj1-x232.google.com with SMTP id e17so8499258ljf.13 for <resolverless-dns@ietf.org>; Wed, 04 Sep 2019 05:58:32 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=umich.edu; s=google-2016-06-03; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=ehBgeI+/TSIEXTTJfdfZfCAyu1wzU5vtwEtuy6ZqnS0=; b=LCMnMuYiv5qXOwJaaimurc1aSCC0NBjIsx8NO1k3gyUC03pxLxDIf1YZwuooaULzmA mQ4I3n2c1D34PV96pSeTE0eV2gnRa0BJxrZexwm6Hq1mM8tVgfm9yhyr/GmP6Ul8zYVf ZFTCvWCkBTd/Ub/r7ANmgyGfM7Ao+zSVtW/6ewNTza5LdiGC4TEsAk5OhNnB5bt2YLd4 7sc0gMOIUcIOG9Au9BHUKCGmgPVepKBK5CpJPCLbECVI9J9ZNHjcH5xsLkWigI2LsSQW dbYERqo47eeD8T+X8rWO6VFHHPGDtLq8D1YrZX/HzH3bz3zmtNXDmnVfU+xp9SQoYB1w mu0w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=ehBgeI+/TSIEXTTJfdfZfCAyu1wzU5vtwEtuy6ZqnS0=; b=cLCjRYeQ8xh1L393zUMnGVLqs6Kr4oTqximn4pdpMM60tO4EL+z3wAcdUFAHuSZEJn lcih6iCnD87iIPuebzsdSjUjctKYz4OwuX5ehcGt6TyVg9/4B2i0e3bYmudsmTywHlKt liDQOqXphh0boeD9YjTy2kSEkjXyYLy0wGStXI1Mlkppj88sjuWAQ18CJQzbyuXJknRh 0ORDb5oTEt226nMwgdQWBDHFdxFw8Yziebc3t+kDRqpNPIQ6FSB7i+pxKGvu3YEKzvtH 4XAASTcNge3Rk4h1L0l887AMJZ0f+QDMcYWhkc9IhJka8h5nyaifRtg33n7BiBlBMj6i bdEw==
X-Gm-Message-State: APjAAAWWXji1Xb/ui0s160MeFa/Zp/XBC/XDxNs+abFwp3DUxRw3HedS xN2uNGsGfVpCECVFpyVlu0zE2X4XSgv4URXC1W+fUa0/WSA=
X-Google-Smtp-Source: APXvYqwjS+iH3vhF3sKzz+1umArwCugAx90FGCdmNEBmwv2sZUkoFykxvGKUOohtWD5gkbqWXZq59I5OqHvlKDI6NlM=
X-Received: by 2002:a2e:81cb:: with SMTP id s11mr22312354ljg.179.1567601910003; Wed, 04 Sep 2019 05:58:30 -0700 (PDT)
MIME-Version: 1.0
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> <88cef6e4-73bd-7324-8509-a1acbd77750e@informatik.uni-hamburg.de>
In-Reply-To: <88cef6e4-73bd-7324-8509-a1acbd77750e@informatik.uni-hamburg.de>
From: Bob Harold <rharolde@umich.edu>
Date: Wed, 04 Sep 2019 08:58:18 -0400
Message-ID: <CA+nkc8CLO7TwB1zFstjSCGNBvWUaBX1E2uvBQOkSMEAmFxP3yA@mail.gmail.com>
To: sy@informatik.uni-hamburg.de
Cc: resolverless-dns@ietf.org
Content-Type: multipart/alternative; boundary="000000000000fecdd70591b9c257"
Archived-At: <https://mailarchive.ietf.org/arch/msg/resolverless-dns/6SNkfriZMdU3MnQTYGwADIf3oOs>
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: Wed, 04 Sep 2019 12:58:36 -0000

On Tue, Sep 3, 2019 at 5:32 PM Erik Sy <sy@informatik.uni-hamburg.de> wrote:

>
> 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.
>

I find in Section 3.2.2:  "As a result, we recommend
user agents to restrict the contexts in which they trust the DNS records
retrieved via resolverless DNS. For example, web browsers can restrict the
usage of such DNS records within the context of the same browser tab or the
same website."

But I don't understand what is meant by "the same website".  If it means
the same hostname, then the DNS entry has already been found, to get to the
website, and there is no need for resolverless DNS or any DNS lookup.  What
else could it mean?

-- 
Bob Harold



> 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
>
>
>
> --
> Resolverless-dns mailing list
> Resolverless-dns@ietf.org
> https://www.ietf.org/mailman/listinfo/resolverless-dns
>