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

Paul Ebersman <list-dnsop@dragon.net> Tue, 21 August 2018 02:26 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 246E1130E8C for <dnsop@ietfa.amsl.com>; Mon, 20 Aug 2018 19:26:30 -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 qs1M3XVkoWjM for <dnsop@ietfa.amsl.com>; Mon, 20 Aug 2018 19:26:27 -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 AFECE130E72 for <dnsop@ietf.org>; Mon, 20 Aug 2018 19:26:27 -0700 (PDT)
Received: from fafnir.remote.dragon.net (localhost [IPv6:::1]) by mail.dragon.net (Postfix) with ESMTP id 797DD37401C3; Mon, 20 Aug 2018 19:26:27 -0700 (PDT)
Received: by fafnir.remote.dragon.net (Postfix, from userid 501) id 50A64AD6A31; Mon, 20 Aug 2018 20:26:27 -0600 (MDT)
Received: from fafnir.local (localhost [127.0.0.1]) by fafnir.remote.dragon.net (Postfix) with ESMTP id 4FF5DAD6A30; Mon, 20 Aug 2018 20:26:27 -0600 (MDT)
From: Paul Ebersman <list-dnsop@dragon.net>
To: Tom Pusateri <pusateri@bangj.com>
cc: dnsop <dnsop@ietf.org>
In-reply-to: <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> <922DCF48-BA8A-42B8-99BA-2B367D981568@bangj.com>
Comments: In-reply-to Tom Pusateri <pusateri@bangj.com> message dated "Mon, 20 Aug 2018 22:13:41 -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: <55365.1534818387.1@fafnir.local>
Date: Mon, 20 Aug 2018 20:26:27 -0600
Message-Id: <20180821022627.50A64AD6A31@fafnir.remote.dragon.net>
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/ffkZ1D9m2PzO3Skibg0KmIhKuUc>
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:26:43 -0000

ebersman> That may be the consensus at the IETF but it's not even close
ebersman> the consensus with ISPs, nor large enterprise. That seems to
ebersman> cover most of the eyeball/consumer... DHCP is still how much
ebersman> of the world gets connected and that hasn't changed in decades.

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

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

And I'd argue that this is also an IETF opinion, not the majority of the
internet. There's a reason it's still the most widespread configuration
management for devices. "Not trustworthy enough to extend" is a fine
academic opinion but doesn't hold water in the marketplace.

DHCP is no worse currently than TOFU. We trust that the OFFER packet
will be from the DHCP server we're supposed to use. Trust On First
Use. Not great but it works more than not. At least that's the argument
I kept hearing for TOFU. We actually have operational experience of
decades for DHCP and this isn't a wide spread enough problem to kill any
innovation forever because it's not perfect.

If we want the world to use what the IETF develops, we have to be able
to balance theoretical risk vs sane and widespread deployment.

If not, someone will just wind up shoving this into yet another DHCP
vendor option and every vendor will be different. That will be even less
secure.