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

Paul Vixie <paul@redbarn.org> Wed, 22 August 2018 18:48 UTC

Return-Path: <paul@redbarn.org>
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 98CD4130E44 for <dnsop@ietfa.amsl.com>; Wed, 22 Aug 2018 11:48:59 -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, RCVD_IN_DNSWL_NONE=-0.0001, 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 tqyQukgNgwl2 for <dnsop@ietfa.amsl.com>; Wed, 22 Aug 2018 11:48:58 -0700 (PDT)
Received: from family.redbarn.org (family.redbarn.org [24.104.150.213]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3B30D130E2F for <dnsop@ietf.org>; Wed, 22 Aug 2018 11:48:58 -0700 (PDT)
Received: from [IPv6:2001:559:8000:c9:9061:ce0d:93bf:336d] (unknown [IPv6:2001:559:8000:c9:9061:ce0d:93bf:336d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by family.redbarn.org (Postfix) with ESMTPSA id 1EF2A892C6; Wed, 22 Aug 2018 18:48:58 +0000 (UTC)
Message-ID: <5B7DB016.1030003@redbarn.org>
Date: Wed, 22 Aug 2018 11:48:54 -0700
From: Paul Vixie <paul@redbarn.org>
User-Agent: Postbox 5.0.25 (Windows/20180328)
MIME-Version: 1.0
To: Ted Lemon <mellon@fugue.com>
CC: Vittorio Bertola <vittorio.bertola@open-xchange.com>, dnsop WG <dnsop@ietf.org>, David Conrad <drc@virtualized.org>
References: <CAC=TB13mUH2SDxFb4c3rOz0-Z6PE_r9i84_xK=dmLxiVr45+tA@mail.gmail.com> <CAPt1N1n9hDUZQ-Ltvs73T20=fpG-FR_j-t4m0kMapDiv2Us1kw@mail.gmail.com> <5B78BFB9.40103@redbarn.org> <47508D79-0D49-4F31-9BA6-6DC80C38F1DE@cable.comcast.com> <ad1f6dff-ebcc-97a9-6f4b-1ed683827cc7@dougbarton.us> <1313743534.13562.1534765718802@appsuite.open-xchange.com> <9AFE57A7-1D27-4F86-9013-E3C63E63C582@hopcount.ca> <5B7AE322.3020201@redbarn.org> <CAPt1N1m-Xd-7rvgmk8GOsx34=1hsu76nmTgW-8krC3JF7i57KQ@mail.gmail.com> <265867956.15518.1534783313366@appsuite.open-xchange.com> <CAPt1N1myrdOywur35rXRab2QCrhFiJ0vS4wnT_Pof0epdOPz7A@mail.gmail.com> <471139805.18285.1534847636363@appsuite.open-xchange.com> <FBE862C5-6999-4D2F-A877-4ACDF1F5FBF1@virtualized.org> <318323950.21554.1534926760460@appsuite.open-xchange.com> <CAPt1N1nFATxZQaw0kEwpaAFK67otwVCLfvOgg8+CLDasV66MQw@mail.gmail.com> <5B7DAA47.6010503@redbarn.org> <CAPt1N1=5p9EZ0yjsVcTLRRZbxdyEwzeY+wNs3AnrDv3xbs7_cw@mail.gmail.com>
In-Reply-To: <CAPt1N1=5p9EZ0yjsVcTLRRZbxdyEwzeY+wNs3AnrDv3xbs7_cw@mail.gmail.com>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/5AH5NBkIlPR3ofGddJLzVHMlu6k>
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: Wed, 22 Aug 2018 18:49:00 -0000


Ted Lemon wrote:
> It's never been up to the DHC working group to decide whether new DHCP
> options are architecturally good.   People have often used the DHC
> working group as a way to skate by due diligence on architectural
> considerations; this was considered to be a problem even before I was
> chair, and we burned a lot of time evaluating bad ideas before we
> decided not to be the place where new work on DHCP options is done by
> default.   If a DHCP option were to be entertained, this WG, the dprive
> WG or the DoH WG would be where it would have to happen, not because the
> DHC working group is freezing new features, but because it's not in
> their charter.

you, as an author of two implementations as a former DHC WG chair, have 
said that new features should not be added to DHCP because 
authentication. while i disagree, i recognize that your voice has more 
credibility in the DHCP space than mine does, and i'm ready to give up 
rather than actually fight and lose the battle.

> That said, you responded to a message where I talked about what I think
> we ought to do to move forward by saying that moving forward is
> impossible other than by just adding a hack somewhere.   I don't think
> that's true, and in fact I'm feeling like I need to write up a threat
> analysis because even though it's not something that I want to work on,
> it sounds like most people assume it's impossible and I'm just
> suggesting it as a roadblock, and the people who get that it's necessary
> don't seem to be any more enthusiastic about doing it than I am.   I'd
> appreciate it if, when I've written that analysis, you could contribute
> to it, but I'll understand if you don't have time or don't think it's
> worthwhile.

my own experience as a widely unread author is that i have to keep 
things short or people will refile/delete them, no matter how 
meritorious or relevant (or even pithy and clever) the writing was.

-- 
P Vixie