Re: [DNSOP] Draft for dynamic discovery of secure resolvers

Tony Finch <dot@dotat.at> Tue, 21 August 2018 11:16 UTC

Return-Path: <dot@dotat.at>
X-Original-To: dnsop@ietfa.amsl.com
Delivered-To: dnsop@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B0909130EB7 for <dnsop@ietfa.amsl.com>; Tue, 21 Aug 2018 04:16:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.199
X-Spam-Level:
X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, URIBL_BLOCKED=0.001] autolearn=unavailable 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 Ei5-W7k8fuzZ for <dnsop@ietfa.amsl.com>; Tue, 21 Aug 2018 04:16:02 -0700 (PDT)
Received: from ppsw-30.csi.cam.ac.uk (ppsw-30.csi.cam.ac.uk [131.111.8.130]) (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 51CF4130E04 for <dnsop@ietf.org>; Tue, 21 Aug 2018 04:16:02 -0700 (PDT)
X-Cam-AntiVirus: no malware found
X-Cam-ScannerInfo: http://help.uis.cam.ac.uk/email-scanner-virus
Received: from grey.csi.cam.ac.uk ([131.111.57.57]:46286) by ppsw-30.csi.cam.ac.uk (ppsw.cam.ac.uk [131.111.8.136]:25) with esmtps (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) id 1fs4dj-000zYM-dF (Exim 4.91) (return-path <dot@dotat.at>); Tue, 21 Aug 2018 12:15:59 +0100
Date: Tue, 21 Aug 2018 12:15:59 +0100
From: Tony Finch <dot@dotat.at>
To: Marek Vavruša <mvavrusa=40cloudflare.com@dmarc.ietf.org>
cc: dnsop <dnsop@ietf.org>
In-Reply-To: <alpine.DEB.2.20.1808201720060.3596@grey.csi.cam.ac.uk>
Message-ID: <alpine.DEB.2.20.1808211154460.3596@grey.csi.cam.ac.uk>
References: <CAC=TB13mUH2SDxFb4c3rOz0-Z6PE_r9i84_xK=dmLxiVr45+tA@mail.gmail.com> <alpine.DEB.2.20.1808201720060.3596@grey.csi.cam.ac.uk>
User-Agent: Alpine 2.20 (DEB 67 2015-01-07)
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/zRIj2qk2usMBjSyqLtnSnmyRauQ>
Subject: Re: [DNSOP] Draft for dynamic discovery of secure resolvers
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.27
Precedence: list
List-Id: IETF DNSOP WG mailing list <dnsop.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dnsop>, <mailto:dnsop-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dnsop/>
List-Post: <mailto:dnsop@ietf.org>
List-Help: <mailto:dnsop-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnsop>, <mailto:dnsop-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 21 Aug 2018 11:16:05 -0000

Tony Finch <dot@dotat.at> wrote:
>
> A URI template usually implies the need for DNS queries to resolve the
> server name (unless it's an address literal). Would it be plausible to
> allow the client to assume that the DoH server IP addresses are the same
> as the DNS server addresses, so it can skip the lookup? I guess that would
> be too annoying for operators that want their DoH servers to be separate
> from their normal DNS resolvers, so maybe it's a bad idea :-)

There was an interesting discussion on Twitter last night -
https://twitter.com/PowerDNS_Bert/status/1031284355686178817

Bert Hubert made the point that https has a lot more opportunities for
identifying and tracking individual devices, compared to trad DNS. Home
gateways that act as DNS relays help with individual privacy, especially
if they also cache.

I think the implications of this, and the arguments that Paul Vixie has
been making, are that there will be unexpected privacy and security upsets
if the DoH resolution path is too different from the trad DNS resolution
path.

This is really a problem with how DoH is deployed and used. So it's
important to make it easy for operators to deploy DoH in a way that
doesn't have surprising privacy leaks when it is supposed to be a
privacy-enhancing technology. DHCP options can help to make all the
DoTH stuff behave in a similar way to the network's trad DNS - it's much
simpler from the user's perspective if they only need to worry about how
respectful or abusive their network provider is as a whole, without having
to get into the details of exactly which resolution protocol they are
using.

Tony.
-- 
f.anthony.n.finch  <dot@dotat.at>  http://dotat.at/
Humber, Thames, Dover: Southwest 4 or 5, occasionally 6, except in Humber.
Slight, occasionally moderate. Fog patches at first. Moderate or good,
occasionally very poor at first.