Re: [dns-privacy] Trying to understand DNS resolver 'discovery'

Neil Cook <neil.cook@noware.co.uk> Wed, 27 November 2019 14:40 UTC

Return-Path: <neil.cook@noware.co.uk>
X-Original-To: dns-privacy@ietfa.amsl.com
Delivered-To: dns-privacy@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 383771208F3 for <dns-privacy@ietfa.amsl.com>; Wed, 27 Nov 2019 06:40:27 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.846
X-Spam-Level:
X-Spam-Status: No, score=-0.846 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, HTML_OBFUSCATE_05_10=0.26, RDNS_NONE=0.793, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no 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 6j1KcCztc6lR for <dns-privacy@ietfa.amsl.com>; Wed, 27 Nov 2019 06:40:25 -0800 (PST)
Received: from mail.noware.co.uk (unknown [IPv6:2604:a880:0:1010::add:2001]) by ietfa.amsl.com (Postfix) with ESMTP id 938551208E4 for <dns-privacy@ietf.org>; Wed, 27 Nov 2019 06:40:25 -0800 (PST)
Received: from [192.168.1.170] (unknown [81.151.217.120]) by mail.noware.co.uk (Postfix) with ESMTPSA id 428E01C6541; Wed, 27 Nov 2019 14:29:54 +0000 (UTC)
From: Neil Cook <neil.cook@noware.co.uk>
Message-Id: <008AE77C-7340-4ECA-BDDB-CDEFE1087EAF@noware.co.uk>
Content-Type: multipart/alternative; boundary="Apple-Mail=_736FFFD5-0362-4788-99E0-0336D2479E66"
Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3601.0.10\))
Date: Wed, 27 Nov 2019 14:40:23 +0000
In-Reply-To: <CY4PR1601MB1254D915F946F255B2B53DC8EA440@CY4PR1601MB1254.namprd16.prod.outlook.com>
Cc: Stephane Bortzmeyer <bortzmeyer@nic.fr>, "dns-privacy@ietf.org" <dns-privacy@ietf.org>, Phillip Hallam-Baker <phill@hallambaker.com>
To: "Konda, Tirumaleswar Reddy" <TirumaleswarReddy_Konda@mcafee.com>
References: <CAMm+Lwig+90Riqav6BT6D-0n4pZJFgAr3p996Q+qXJSPt0kqBQ@mail.gmail.com> <20191126180441.GA4452@sources.org> <4E2DE849-CC35-4675-9A41-CD134D65371A@noware.co.uk> <CY4PR1601MB1254D915F946F255B2B53DC8EA440@CY4PR1601MB1254.namprd16.prod.outlook.com>
X-Mailer: Apple Mail (2.3601.0.10)
X-VADE-SPAMSTATE: clean
X-VADE-SPAMSCORE: -100
X-VADE-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrgedufedrudeihedgieehucetufdoteggodetrfdotffvucfrrhhofhhilhgvmecupffgkffnvefqqffmnecuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenucfjughrpefhkfgtggfuffgjvfhfofesrgdtmherhhdtjeenucfhrhhomheppfgvihhlucevohhokhcuoehnvghilhdrtghoohhksehnohifrghrvgdrtghordhukheqnecuffhomhgrihhnpehmhihishhprdhnvghtnecukfhppeekuddrudehuddrvddujedruddvtdenucfrrghrrghmpehinhgvthepkedurdduhedurddvudejrdduvddtpdhhvghloheplgduledvrdduieekrddurddujedtngdpmhgrihhlfhhrohhmpefpvghilhcuvehoohhkuceonhgvihhlrdgtohhokhesnhhofigrrhgvrdgtohdruhhkqedprhgtphhtthhopefvihhruhhmrghlvghsfigrrhftvgguugihpgfmohhnuggrsehmtggrfhgvvgdrtghomhdprhgtphhtthhopegsohhrthiimhgvhigvrhesnhhitgdrfhhrpdhrtghpthhtohepughnshdqphhrihhvrggthiesihgvthhfrdhorhhgpdhrtghpthhtohepphhhihhllheshhgrlhhlrghmsggrkhgvrhdrtghomhenucevlhhushhtvghrufhiiigvpedt
Archived-At: <https://mailarchive.ietf.org/arch/msg/dns-privacy/r0PazegGSDm2cDqHAeOENWetiD8>
Subject: Re: [dns-privacy] Trying to understand DNS resolver 'discovery'
X-BeenThere: dns-privacy@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: <dns-privacy.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dns-privacy>, <mailto:dns-privacy-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dns-privacy/>
List-Post: <mailto:dns-privacy@ietf.org>
List-Help: <mailto:dns-privacy-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dns-privacy>, <mailto:dns-privacy-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 27 Nov 2019 14:40:27 -0000


> On 27 Nov 2019, at 14:22, Konda, Tirumaleswar Reddy <TirumaleswarReddy_Konda@mcafee.com> wrote:
> 
>> 
>> Resolver discovery schemes allow a client to ask the local resolver to provide
>> information about the resolver, such as DoH info, as well as potentially other
>> information about the resolver. I don’t see why they’re broken by design;
>> yes they add no security properties on top of the (insecure) DHCP
>> mechanism used to contact the resolver in the first place, but how clients use
>> that information is up to them. They may or may not decide to trust that
>> resolver, 
> 
> The problem with DHCP is the client has no way to know whether the DoT/DoH server is indeed hosted by the local network or by an attacker. For example, consider a network using Quad9/OpenDNS to perform malware filtering but attacker spoofs the DHCP response to convey the network is using CloudFlare DNS server. Chrome would establish DoH with CloudFlare, and the attack is successful. It is also easy for the attacker to get a domain name, and get the certificate signed by the CA (domain validate certificate).
> 

I’m not arguing that DHCP is secure, I’m arguing that discovery isn’t worthless., The client is free to use other mechanisms to decide whether to trust the DoH server returned as part of the discovery mechanism. For example if the resolver discovery returns the DoH server for that resolver as “myisp.net”, then the client can verify not only that the certificate matches myisp.net <http://myisp.net/>, but also whether it trusts “myisp.net <http://myisp.net/>” for DNS resolution. This is essentially the approach that Chrome is already taking with DoH, except that it currently lacks the discovery part.

Another use-case for discovery would be the case where I have manually entered a DNS server (e.g. 1.1.1.1). By default I can use DNS53 or DoT to that server, but not DoH. However with discovery I could ask (using either DNS53 or DoH) the 1.1.1.1 resolver if it supports DoH and if so on what URL.

Neil