Re: [DNSOP] Draft for dynamic discovery of secure resolvers

bert hubert <bert.hubert@powerdns.com> Sat, 18 August 2018 23:03 UTC

Return-Path: <bert@hubertnet.nl>
X-Original-To: dnsop@ietfa.amsl.com
Delivered-To: dnsop@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3AA5A130F40 for <dnsop@ietfa.amsl.com>; Sat, 18 Aug 2018 16:03:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.736
X-Spam-Level:
X-Spam-Status: No, score=-1.736 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DRUGS_MUSCLE=0.164, HEADER_FROM_DIFFERENT_DOMAINS=0.001, SPF_PASS=-0.001] autolearn=no 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 epVE4wvIfxGt for <dnsop@ietfa.amsl.com>; Sat, 18 Aug 2018 16:03:24 -0700 (PDT)
Received: from xs.powerdns.com (xs.powerdns.com [82.94.213.34]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D5E67130F39 for <dnsop@ietf.org>; Sat, 18 Aug 2018 16:03:23 -0700 (PDT)
Received: from server.ds9a.nl (unknown [86.82.68.237]) by xs.powerdns.com (Postfix) with ESMTPS id 06E679FB55; Sat, 18 Aug 2018 23:03:19 +0000 (UTC)
Received: by server.ds9a.nl (Postfix, from userid 1000) id 4E356AC6AEA; Sun, 19 Aug 2018 01:03:19 +0200 (CEST)
Date: Sun, 19 Aug 2018 01:03:19 +0200
From: bert hubert <bert.hubert@powerdns.com>
To: Ted Lemon <mellon@fugue.com>
Cc: Marek =?utf-8?Q?Vavru=C5=A1a?= <mvavrusa=40cloudflare.com@dmarc.ietf.org>, dnsop <dnsop@ietf.org>
Message-ID: <20180818230319.GA32131@server.ds9a.nl>
References: <CAC=TB13mUH2SDxFb4c3rOz0-Z6PE_r9i84_xK=dmLxiVr45+tA@mail.gmail.com> <CAPt1N1=-792WkQmbTigPdqOh0dONykYycG0hheOecoQa4ai=Hw@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <CAPt1N1=-792WkQmbTigPdqOh0dONykYycG0hheOecoQa4ai=Hw@mail.gmail.com>
User-Agent: Mutt/1.5.24 (2015-08-30)
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/IrvT3LI90javCwJ8XSZ-7Tc1HZE>
Subject: Re: [DNSOP] Draft for dynamic discovery of secure resolvers
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.27
Precedence: list
List-Id: IETF DNSOP WG mailing list <dnsop.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dnsop>, <mailto:dnsop-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dnsop/>
List-Post: <mailto:dnsop@ietf.org>
List-Help: <mailto:dnsop-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnsop>, <mailto:dnsop-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 18 Aug 2018 23:03:26 -0000

On Sat, Aug 18, 2018 at 05:22:53PM -0400, Ted Lemon wrote:
> 1. Why is DoH being used?
> 2. What is the thread model that DoH is addressing?

That not yet enough of the internet has been centralized on big cloud
providers in foreign jurisdictions, I think.

(this post does get DNS operational after a few paragraphs)

It borders on the ridiculous that we have CDNs and browser vendors pushing
this service for free, at great cost, claiming they are doing it out of the
goodness of their hearts.

I can imagine the board meeting already in the SOMA district in SF. Big
powerpoint presentation. "We're going to allocate resources to enhance the
privacy of people who aren't even our customers". Investor representatives
look up and ask "why??", well goes the response, because we lie awake at
night that some providers are attempting to monetize DNS, and we can't let
this horrible invasion of privacy continue unabated!

Meanwhile said users are browsing webpages laden with trackers by dozens of
companies already monetizing that traffic. 

Furthermore, the DNS of >600 million people is already hosted by service
providers not allowed to monetize DNS.  So for a ton of people, we're moving
DNS from highly regulated telecommunications companies to a VC-backed CDN
that cooperates closely with heavily censoring regimes in order to get
business.

Additionally, the operational community is up in arms since this move will
break their intranet, their local security policies, their VPN domain
overrides and their threat monitoring. 

The CDN providers have also made it clear they will colocate the DoH service
on IP addresses that carry "unblockable" content, forcing system
administrators into a Solomon judgment: shall we take down the CDN that
carries 'jquery' and break half the internet, or shall we allow
uninspectable DNS? 

In this way, popular content serves as a human shield to protect DoH against
blocking.

Malware authors will surely love this dilemma too and be sure to move all
their DNS lookups to the colocated service - where we can never spot them.

But apparently the interest in enhancing users privacy by moving DNS to a
third party, by default, is so large that all these worries do not matter. I
find this very hard to believe.

(Mind you - Mozilla is on record that they want to turn this on by default. 
There has been some weaselwording around this on Twitter by people claiming
not to speak for Mozilla, but no denial.  So for now, we can safely assume
they are seriously intending to turn on DoH by default -
https://blog.ungleich.ch/en-us/cms/blog/2018/08/04/mozillas-new-dns-resolution-is-dangerous/
)

I've been trying to understand what everyone is up to, but I find myself in
a 'Sherlock Holmes' situation where all reasonable explanations don't work.
Why is there this massive push to enable DoH by default?

The CDN providers in question must adhere to strict privacy policies and
allow themselves to be audited. So there's no immediate monetization
possible.

However, looking up all domain names with CDN provider A does mean users
would then, by default, have to access all sites hosted at CDN provider B
through provider A. 

This is an area where "rent seeking" https://en.wikipedia.org/wiki/Rent-seeking
is entirely possible. 

And lo, we are already seeing it! CDN Provider B relies on EDNS Client
Subnet for some of the largest service providers in the world and CDN
provider A is not going to supply those 24 bits of address to CDN provider
B!

Immediately, rolling out DoH by default is going to hurt CDN provider B.

I realise I'm screaming into the void a bit, but whenever someone says
"centralise this stuff on me, it will be better, and I'm spending big on it
for the love of your privacy", I am worried. 

Especially when such a move will incidentally kill intranets, VPNs, split
horizon, DNS monitoring & DNS malware detecion and blocking. 

So to round this off - I am not clear what threat
DoH-in-the-browser-to-a-third-party is protecting us against.

	Bert

> 3 How does adding this configuration mechanism impact DoH's ability to
> address that threat model?
> 
> On Sat, Aug 18, 2018 at 5:17 PM, Marek Vavruša <
> mvavrusa=40cloudflare.com@dmarc.ietf.org> wrote:
> 
> > Hi,
> >
> > this is a bit off topic, but I figured it would be useful to solicit
> > some early feedback. The current status is that for secure (as in
> > RFC7858 DoT or DoH) resolvers is that there's no discovery mechanism,
> > and it's also out of scope for [0]. At the same time we're seeing real
> > world deployment of clients which either:
> >
> > a) Probe port 853 and use DoT in opportunistic profile, or probe 443
> > and trust WebPKI
> > b) Statically configure ADN and/or SPKI pins with well known public
> > resolvers
> >
> > This approach works if there's someone maintaining the statically
> > configured information, as with the dnscrypt-proxy stamp lists [1].
> > However in most networks the default resolver configuration is pushed
> > through DHCP, so it's the network operator that's in charge for
> > providing default DNS resolver configuration (unless the user is a DNS
> > aficionado and overrides it), but there's currently no good way to
> > provide information required to identify and securely bootstrap a
> > connection to a resolver using DoT or DoH.
> >
> > This draft adds an option to provide a capability list for each
> > configured resolver. The three defined capabilities are TLS with SPKI
> > pin, TLS with ADN, HTTPS. The idea is that DHCP clients reads this
> > information and stores it similarly to resolver list and domain search
> > path for applications to read. Another possible solution for this is
> > to use the system of stamps from dnscrypt-proxy, but it's probably
> > less legible for clients and duplicates information that's already in
> > the recursive DNS nameservers DHCPv4/v6 option.
> >
> > The draft does not change the trust model, an end-user or an
> > application can still disregard DNS recursive nameserver list from
> > DHCP, for better or worse.
> >
> > Here's the draft:
> > https://github.com/vavrusa/draft-dhcp-dprive/blob/master/
> > draft-dhcp-dprive.txt
> >
> > Marek
> >
> > [0]: https://trac.tools.ietf.org/html/rfc8310#section-7.3.1
> > [1]: https://download.dnscrypt.info/dnscrypt-resolvers/v2/
> > public-resolvers.md
> >
> > _______________________________________________
> > DNSOP mailing list
> > DNSOP@ietf.org
> > https://www.ietf.org/mailman/listinfo/dnsop
> >

> _______________________________________________
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop