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

Paul Ebersman <list-dnsop@dragon.net> Tue, 21 August 2018 01:40 UTC

Return-Path: <list-dnsop@dragon.net>
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 C7370130DF6 for <dnsop@ietfa.amsl.com>; Mon, 20 Aug 2018 18:40:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 2EuVOEVRZWM9 for <dnsop@ietfa.amsl.com>; Mon, 20 Aug 2018 18:40:31 -0700 (PDT)
Received: from mail.dragon.net (mail.dragon.net [IPv6:2001:4f8:3:36::235]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CDC6F130DF2 for <dnsop@ietf.org>; Mon, 20 Aug 2018 18:40:31 -0700 (PDT)
Received: from fafnir.remote.dragon.net (localhost [IPv6:::1]) by mail.dragon.net (Postfix) with ESMTP id F3FDE3740178 for <dnsop@ietf.org>; Mon, 20 Aug 2018 18:40:30 -0700 (PDT)
Received: by fafnir.remote.dragon.net (Postfix, from userid 501) id C2678AD6354; Mon, 20 Aug 2018 19:40:30 -0600 (MDT)
Received: from fafnir.local (localhost [127.0.0.1]) by fafnir.remote.dragon.net (Postfix) with ESMTP id BAAC9AD6353 for <dnsop@ietf.org>; Mon, 20 Aug 2018 19:40:30 -0600 (MDT)
From: Paul Ebersman <list-dnsop@dragon.net>
To: dnsop <dnsop@ietf.org>
In-reply-to: <B5CCB149-BEE2-46D4-BF3C-C32D5BCA3EA3@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>
Comments: In-reply-to Tom Pusateri <pusateri@bangj.com> message dated "Mon, 20 Aug 2018 21:22:42 -0400."
X-Mailer: MH-E 7.4.2; nmh 1.7.1; XEmacs 21.4 (patch 22)
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <54266.1534815630.1@fafnir.local>
Date: Mon, 20 Aug 2018 19:40:30 -0600
Message-Id: <20180821014030.C2678AD6354@fafnir.remote.dragon.net>
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/N6yxLga9NOEi27d7i5YycPKWgSs>
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:40:34 -0000

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.

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

The google/android crowd's bias against DHCP and DHCPv6 is well known
and is why android is having trouble penetrating said enterprise
market.

Getting DOH via DHCP is the same argument as TOFU and the IETF has used
TOFU.

DHCP is how hotspots, ISPs and enterprise work. Users able to understand
security risks and who read drafts from the IETF already know how to
deal with this and won't need a DHCP option. Much of the world does need
and want configure hosts/devices via DHCP.

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.