Re: [Doh] ISP position re. hardcoded DoH servers

Ted Lemon <mellon@fugue.com> Thu, 25 July 2019 19:43 UTC

Return-Path: <mellon@fugue.com>
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 750071201CE for <doh@ietfa.amsl.com>; Thu, 25 Jul 2019 12:43:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level:
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, MIME_QP_LONG_LINE=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=fugue-com.20150623.gappssmtp.com
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 Be9U4kLEqgei for <doh@ietfa.amsl.com>; Thu, 25 Jul 2019 12:43:40 -0700 (PDT)
Received: from mail-ua1-x92d.google.com (mail-ua1-x92d.google.com [IPv6:2607:f8b0:4864:20::92d]) (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 925C91201C6 for <doh@ietf.org>; Thu, 25 Jul 2019 12:43:40 -0700 (PDT)
Received: by mail-ua1-x92d.google.com with SMTP id 8so20318178uaz.11 for <doh@ietf.org>; Thu, 25 Jul 2019 12:43:40 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=ZRwI6Ww+IbJfES6pni0dRpQvQdGEmhAnhztCNlGpIhg=; b=PE1HO171afkiYbxwEO0GPzNpGs4Rn92/8q3WrDcer+uFunOIG4sxPR4/3292x5be4Q VJqa4xbZEm6QvA2umvX3o/sN68/HDcs09cvNCGtuul3lHqZ2l9KbVQhgcGZqY0x6QNfd ckDkIL3sttzE+LwSQ7Ic/XI3uESaYFOIdf+lowv0IuwCrT/QxNEw1LnFh0LP9ko7qTvf xvzNtrDmQKlKj6Czic0GrMj/V4yfXWMpQ+k8Xwc5ioTZf6a4l6PYq1/c1pKeYPwL6H/O 0GXn9YriCdbLxKyrBmvmEtQdXY1l1Nj/Hz8fXz5Mr8uXctiPGRqLMePxbmiSWhkOtqbI wvtQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=ZRwI6Ww+IbJfES6pni0dRpQvQdGEmhAnhztCNlGpIhg=; b=eVZ0QoHL/GJiEZvSPnrCdP/BD0BtCPE+1nJ3hsYMjq3GAs//9qC08WuYI9nGooBbF2 a93ygWvML9rHbp177DZjIVEYfISJ+OCNf4RA1LHMIO8+vNnqKWkqXVy/6JQCH9EDG+RE hVhNcAeoynbCHxNyRRoD83rTKV9TRAkn0w0ZZKuPfOCXcSz8tErN9zC031x/4KSnj4mY wbo3N+f/v60wMTOXSvy3dPj+TqHkbAUcFXTFEBVzCrs4Cv9k/rRk4OPR9G927sQ5HgHF Ay4IW9JZ7ihI9L8TmrhGtZqTdIhWULVUXs9TqSxGoztqQLuRiE5szR5JV5n8Hb2VUVjS pg5w==
X-Gm-Message-State: APjAAAWV12tuwJf4k2Te63NrWv2LFXxlFN3dji6zZ/Q1liVk2UCZF+y2 yQflWVGU8vvNjptWMFfeY/26/7WHKONJtA==
X-Google-Smtp-Source: APXvYqzUn2bNNyWvw2zH+541++Sq0H7zzpgVc5eyn/lI1Q+QXGnizxLCQqlmADi7JoqG7IfAWPGywQ==
X-Received: by 2002:ab0:13e2:: with SMTP id n31mr3951853uae.61.1564083819238; Thu, 25 Jul 2019 12:43:39 -0700 (PDT)
Received: from ?IPv6:2001:67c:1232:144:5581:1760:1fae:6b33? ([2001:67c:1232:144:5581:1760:1fae:6b33]) by smtp.gmail.com with ESMTPSA id a23sm2291402vkl.52.2019.07.25.12.43.38 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 25 Jul 2019 12:43:38 -0700 (PDT)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (1.0)
From: Ted Lemon <mellon@fugue.com>
X-Mailer: iPhone Mail (16G77)
In-Reply-To: <20190725183657.GV258193@eidolon.nox.tf>
Date: Thu, 25 Jul 2019 15:43:37 -0400
Cc: doh@ietf.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <4F4BD393-20BA-4797-8665-1CE405B75964@fugue.com>
References: <20190725183657.GV258193@eidolon.nox.tf>
To: David Lamparter <equinox@diac24.net>
Archived-At: <https://mailarchive.ietf.org/arch/msg/doh/62q-g5D39q8Tk1R0xf_DPOWPxUQ>
Subject: Re: [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 19:43:42 -0000

I think there is an assumption in the approach you are taking that the threat model is centralized resolvers tracking users in a transparent way. I don’t think it’s really a philosophical question to ask whether this is indeed the threat mode about which users should be concerned. 

Sent from my iPhone

> On Jul 25, 2019, at 2:36 PM, David Lamparter <equinox@diac24.net> wrote:
> 
> 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 mailing list
> Doh@ietf.org
> https://www.ietf.org/mailman/listinfo/doh