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