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

David Lamparter <equinox@diac24.net> Thu, 25 July 2019 20:12 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 F39951201DB for <doh@ietfa.amsl.com>; Thu, 25 Jul 2019 13:12:17 -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 Expme0sQkcRr for <doh@ietfa.amsl.com>; Thu, 25 Jul 2019 13:12:15 -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 B5D931201E3 for <doh@ietf.org>; Thu, 25 Jul 2019 13:12:15 -0700 (PDT)
Received: from equinox by eidolon.nox.tf with local (Exim 4.92) (envelope-from <equinox@diac24.net>) id 1hqk60-0026th-QT; Thu, 25 Jul 2019 22:12:13 +0200
Date: Thu, 25 Jul 2019 22:12:12 +0200
From: David Lamparter <equinox@diac24.net>
To: Ted Lemon <mellon@fugue.com>
Cc: doh@ietf.org
Message-ID: <20190725201212.GY258193@eidolon.nox.tf>
References: <20190725183657.GV258193@eidolon.nox.tf> <4F4BD393-20BA-4797-8665-1CE405B75964@fugue.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <4F4BD393-20BA-4797-8665-1CE405B75964@fugue.com>
User-Agent: Mutt/1.10.1 (2018-07-13)
Archived-At: <https://mailarchive.ietf.org/arch/msg/doh/ig3EwIaF5a6V1GYoVhee_9c7Zv0>
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 20:12:18 -0000

On Thu, Jul 25, 2019 at 03:43:37PM -0400, Ted Lemon wrote:
> 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.

Ok, let's get into a discussion about whether it's philosophical or
not...

But, first, just for completeness sake, it's been pointed out to me that
browser vendors tried to clarify that they're putting up a user choice
and there is FUD involved here.  I'm perfectly happy if browsers offer
the users the choice to use some DoH server.  That's informed consent.

To Ted's point, I don't care about how to value the threat model of
centralized resolvers tracking their users.  I'm actually not /that/
worried about the resolver operators doing it out of malice.

The problem is that this ends up creating centrally administered
high-value targets.  This concerns me:
- technically, since instances of the same DoH anycast service are
  likely set up close to identically, and likely to be subject to
  similar security issues
- structurally, since a greater number of users can be compromised, or
  even just lose service, by breaking a smaller number of targets
- philosophically, since one centrally administered / coordinated
  structure is more susceptible to subversion or legal compromise than a
  decentralized one.

We live in the age of headline news on database leaks and privacy
breaches.  Of course we'll all do our best to audit our code and
operational practices and make them as unlikely as possible.  But, sh*t
/will/ hit the fan at some point...  I decided I prefer a few smaller
turds over one big one.

These *are* problems even if people have informed consent.  But, if they
opted to use Gooflare or Netzilla DNS - they made their choice, they got
it.

(And we're back to philosophy, because I do see some merit in the
argument that a few competent people might build more secure and private
DNS than a million incompetent ones.)

Cheers,


-David