[Doh] ISP position re. hardcoded DoH servers

David Lamparter <equinox@diac24.net> Thu, 25 July 2019 18:37 UTC

Return-Path: <equinox@diac24.net>
X-Original-To: doh@ietfa.amsl.com
Delivered-To: doh@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 9DBFE1201A0 for <doh@ietfa.amsl.com>; Thu, 25 Jul 2019 11:37:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id I55aW9oibQZG for <doh@ietfa.amsl.com>; Thu, 25 Jul 2019 11:36:59 -0700 (PDT)
Received: from eidolon.nox.tf (eidolon.nox.tf [IPv6:2a07:2ec0:2185::]) (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 815F0120198 for <doh@ietf.org>; Thu, 25 Jul 2019 11:36:59 -0700 (PDT)
Received: from equinox by eidolon.nox.tf with local (Exim 4.92) (envelope-from <equinox@diac24.net>) id 1hqibp-001QCW-1P for doh@ietf.org; Thu, 25 Jul 2019 20:36:57 +0200
Date: Thu, 25 Jul 2019 20:36:57 +0200
From: David Lamparter <equinox@diac24.net>
To: doh@ietf.org
Message-ID: <20190725183657.GV258193@eidolon.nox.tf>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
User-Agent: Mutt/1.10.1 (2018-07-13)
Archived-At: <https://mailarchive.ietf.org/arch/msg/doh/F5Hm6rZSx4-1831aXVw3lX4owl4>
Subject: [Doh] ISP position re. hardcoded DoH servers
X-BeenThere: doh@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: DNS Over HTTPS <doh.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/doh>, <mailto:doh-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/doh/>
List-Post: <mailto:doh@ietf.org>
List-Help: <mailto:doh-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/doh>, <mailto:doh-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 25 Jul 2019 18:37:02 -0000

Hi all,

it happens to be that I run a small ISP in Germany.  Probably one of the
smallest, but this does give me the advantage that I have no company
politics blocking me from things like sending this mail.

First of all, I'm hoping to implement DoH as soon as possible on our
ISP-side DNS caches.  When that happens depends on the availability of
an open source DoH cache, or maybe a DoH to "classical" converter that
we can stack on top of our existing cache.  We'd throw the DNS queries
into our existing resolver either way, so I'd actually prefer a proxy
over a full cache.

At the same time, I will be working to send an all-users bulletin asking
our users for their opinions regarding blocking any known hardcoded DoH
servers in any application.  Since I know our userbase reasonably well,
I can predict that we will indeed be implementing this.  Since we don't
look at any layer 4 headers, this will take the form of simple IP/Prefix
blackhole routes.

Of course you can try and make this as painful as possible by stacking
the DoH service onto something that users will miss.  Maybe some
well-visited front page.  I have no way to isolate DoH traffic from
other HTTPS traffic, and I wouldn't want it any other way.  But I'll
still block anything you hardcode, on layer 3.

I'm doing this because you do not have informed consent from the users
if you ship a general purpose application with some default DoH server.

(btw: Single-purpose applications (e.g. Video streaming services) are a
different story, nothing wrong with hardcoding an e.g. Netflix DoH
server into the Netflix App.  This is about general-purpose things like

The only way you can get informed consent is to present the user with a
dialog box that asks "Do you want to perform all web name queries
through <Service>?  [Yes] [No]".  If you do that, I'll turn into your
advocate instead of adversary.

And while we're at it, I'd like to point out that a hardcoded DoH in an
application is probably illegal in Germany.  German law prohibits /
invalidates "surprising" clauses (BGB §305c), and I'm reasonably
confident a court will agree that sending all unrelated name lookups to
a DoH server of the browser vendor's choice is surprising.  The only way
to fix that is to make it, well, not a surprise.  Maybe ask your lawyers
before you get the GDPR bill.

(again, Netflix app sending DoH to Netflix: no surprise.  Browser
sending all name queries to some DoH: big surprise.)

(I'm not a lawyer, the above is not legal advice, I'm just pointing out
there might be a legal angle to this too.)

It is what it is.  Sorry about that.


P.S.: I don't believe it is useful to respond to this mail.  There's
nothing technical to be discussed here, only philosophy.