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

Tom Pusateri <pusateri@bangj.com> Tue, 21 August 2018 01:22 UTC

Return-Path: <pusateri@bangj.com>
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 CA945130E48 for <dnsop@ietfa.amsl.com>; Mon, 20 Aug 2018 18:22:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 woJ5nQi-BntV for <dnsop@ietfa.amsl.com>; Mon, 20 Aug 2018 18:22:44 -0700 (PDT)
Received: from oj.bangj.com (amt0.gin.ntt.net [129.250.11.170]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BB6ED124D68 for <dnsop@ietf.org>; Mon, 20 Aug 2018 18:22:44 -0700 (PDT)
Received: from [172.16.10.126] (unknown [107.13.224.116]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by oj.bangj.com (Postfix) with ESMTPSA id 69EF52085; Mon, 20 Aug 2018 21:18:44 -0400 (EDT)
From: Tom Pusateri <pusateri@bangj.com>
Message-Id: <B5CCB149-BEE2-46D4-BF3C-C32D5BCA3EA3@bangj.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_863767BA-34E6-478E-92C8-637029E86FED"
Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\))
Date: Mon, 20 Aug 2018 21:22:42 -0400
In-Reply-To: <56B7EA81-A840-4320-BDD0-781E9D999904@vpnc.org>
Cc: dnsop <dnsop@ietf.org>
To: Paul Hoffman <paul.hoffman@vpnc.org>
References: <CAC=TB13mUH2SDxFb4c3rOz0-Z6PE_r9i84_xK=dmLxiVr45+tA@mail.gmail.com> <alpine.DEB.2.20.1808201720060.3596@grey.csi.cam.ac.uk> <23C2BA0B-B4A7-49F2-9FFD-90B90E2928B5@bangj.com> <56B7EA81-A840-4320-BDD0-781E9D999904@vpnc.org>
X-Mailer: Apple Mail (2.3445.9.1)
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/hcPpWMrldj4cv-aRkunYlXVz5CM>
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 01:22:47 -0000

> On Aug 20, 2018, at 9:11 PM, Paul Hoffman <paul.hoffman@vpnc.org> wrote:
> 
> On 20 Aug 2018, at 17:47, Tom Pusateri wrote:
> 
>>> On Aug 20, 2018, at 12:42 PM, Tony Finch <dot@dotat.at> wrote:
>>> 
>>> Marek Vavruša <mvavrusa=40cloudflare.com@dmarc.ietf.org> wrote:
>>>> 
>>>> https://github.com/vavrusa/draft-dhcp-dprive/blob/master/draft-dhcp-dprive.txt
>>> 
>>> This is interesting to me because I want to support DoTH on my campus
>>> resolvers.
>>> 
>>> Regarding DoH, the DHCP option ought to include a URI template (there
>>> isn't a .well-known for DoH). I plan to set up my servers so that
>>> misdirected attempts to get web pages from the DoH server are redirected
>>> to the relevant documentation; that's much easier if the DoH endpoint
>>> isn't at the server root.
>> 
>> Our variant of this same idea that Willem Toorop and I presented at the DRIU BOF in Montréal has a URI for the DoH case:
>> 
>> https://tools.ietf.org/html/draft-pusateri-dhc-dns-driu-00 <https://tools.ietf.org/html/draft-pusateri-dhc-dns-driu-00><https://tools.ietf.org/html/draft-pusateri-dhc-dns-driu-00 <https://tools.ietf.org/html/draft-pusateri-dhc-dns-driu-00>>
>> 
>> But let me remind everyone that there was a lot of people agreeing with Ted in Montréal and so far, Ted appears to be standing all by himself.
>> 
>> Where are all the other folks that shot down this idea earlier? :)
> 
> Judging what was said at an excited mic line is always challenging. :-) Two issues are being conflated here:
> 1) a DHCP option to include a URI template
> 2) how the DHCP client in an OS would use that option
> 
> DHCP options are easy and cheap. However #2 was vexing. The proposal that an OS say "oh look, there is a DoH server, I'll use that because it is more secure than Do53" was what was controversial because of the utter lack of DHCP security. Some of the folks on the mic line disagreed with the assumption that, given two pieces of insecurely-acquired information (a Do53 address and a DoH template) that the latter would result with a more secure connection. A network admin can see the port 53 traffic and see if there's crap in there; they can't see the inner DoH traffic.
> 
> --Paul Hoffman

Yes, this was one good point.

Another point I remember most clearly is that DHCP has fallen out of favor for communicating all but the most minimal network bootstrap configuration information. There was general agreement in the room that you only should use DHCP in IPv4 for address/router info and then use trusted sources for everything else. In IPv6, SLAAC generally provides this.

One more point (from the Android crowd) was that they are going to try to connect to the DNS server’s IP address using port 853 using DoT at the same time they are trying to resolve names over port 53 with UDP. If they’re able to make a DoT connection, they’ll use it. This doesn’t provide for a way to have an ADN to verify the certificate but a PTR query can give you a name to do certificate validation and/or DANE validation. So they seemed to be making the point that no DHCP extensions were necessary.

Tom