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

Tom Pusateri <pusateri@bangj.com> Tue, 21 August 2018 02:13 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 61A74130E09 for <dnsop@ietfa.amsl.com>; Mon, 20 Aug 2018 19:13:45 -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_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 Pu6lsVC0syTE for <dnsop@ietfa.amsl.com>; Mon, 20 Aug 2018 19:13:43 -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 82E9E130DC9 for <dnsop@ietf.org>; Mon, 20 Aug 2018 19:13:43 -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 1BF7620A7; Mon, 20 Aug 2018 22:09:42 -0400 (EDT)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\))
From: Tom Pusateri <pusateri@bangj.com>
In-Reply-To: <20180821014030.C2678AD6354@fafnir.remote.dragon.net>
Date: Mon, 20 Aug 2018 22:13:41 -0400
Cc: dnsop <dnsop@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <922DCF48-BA8A-42B8-99BA-2B367D981568@bangj.com>
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> <B5CCB149-BEE2-46D4-BF3C-C32D5BCA3EA3@bangj.com> <20180821014030.C2678AD6354@fafnir.remote.dragon.net>
To: Paul Ebersman <list-dnsop@dragon.net>
X-Mailer: Apple Mail (2.3445.9.1)
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/t2DgvJ-RY03kqvWm2j70AdLv4WU>
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 02:13:45 -0000


> On Aug 20, 2018, at 9:40 PM, Paul Ebersman <list-dnsop@dragon.net> wrote:
> 
> pusateri> Another point I remember most clearly is that DHCP has fallen
> pusateri> out of favor for communicating all but the most minimal
> pusateri> network bootstrap configuration information. There was general
> pusateri> agreement in the room that you only should use DHCP in IPv4
> pusateri> for address/router info and then use trusted sources for
> pusateri> everything else. In IPv6, SLAAC generally provides this.
> 
> That may be the consensus at the IETF but it's not even close the
> consensus with ISPs, nor large enterprise. That seems to cover most of
> the eyeball/consumer... DHCP is still how much of the world gets
> connected and that hasn't changed in decades.
> 

You’re misquoting me and arguing against a point I didn’t make. There was no one saying we don’t need DHCP. There was a general agreement that DHCP should not be extended.

The DHC working group never completed the work for DHCP authentication. It’s not trustworthy enough in its current form to add more things to it.

> 
> Saying this is all broken and that we need to protect the world from
> themselves by not having a DHCP option simply means that vendors will
> have a slew of non-standard ways of doing it and we've helped noone.
> 
> Let's just give the option, document the security holes and risks and at
> least offer much of the world a standard way of doing this if they so
> choose.

Again, some better understanding of DoH deployment would help. I don’t know if it’s generally accepted that DoH will replace UDP/53 or DoT in the stub resolver or DoH will just end up in the browsers as a way to speed up web pages. But if DoH stays in the browser and DoT is tried and used on all DNS servers, there’s not a problem to solve.

Tom