[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 [127.0.0.1]) 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-Level:
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 ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (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 browsers.) 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. -David P.S.: I don't believe it is useful to respond to this mail. There's nothing technical to be discussed here, only philosophy.
- [Doh] ISP position re. hardcoded DoH servers David Lamparter
- Re: [Doh] ISP position re. hardcoded DoH servers Ted Lemon
- Re: [Doh] ISP position re. hardcoded DoH servers David Lamparter
- Re: [Doh] ISP position re. hardcoded DoH servers JW λ John Woodworth