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

Doug Barton <dougb@dougbarton.us> Sun, 19 August 2018 22:06 UTC

Return-Path: <dougb@dougbarton.us>
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 742EA130DE5 for <dnsop@ietfa.amsl.com>; Sun, 19 Aug 2018 15:06:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=dougbarton.us
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 t_nmOAC2cKn8 for <dnsop@ietfa.amsl.com>; Sun, 19 Aug 2018 15:06:53 -0700 (PDT)
Received: from dougbarton.us (dougbarton.us [IPv6:2607:f2f8:ab14::2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 36E27130DF7 for <dnsop@ietf.org>; Sun, 19 Aug 2018 15:06:53 -0700 (PDT)
Received: from [192.168.10.247] (71-9-84-238.dhcp.snbr.ca.charter.com [71.9.84.238]) by dougbarton.us (Postfix) with ESMTPSA id AE7C679C for <dnsop@ietf.org>; Sun, 19 Aug 2018 15:06:52 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=dougbarton.us; s=dkim; t=1534716412; bh=YxFAuoT9Ds6QqhQJJV/DZ2BcbiKMbIPKpv9a5zj7d94=; h=Subject:To:References:From:Date:In-Reply-To:From; b=i2yBcCPsAJJAxtQMrYoLeFu+kDf7IXDj5TM9X/NXxqOb0H7aHoVakQybn5llnjscZ HYA5rNJDhUktRWtmHYvExHcgA3z+rbXZqAOVgw2KSbpPXCTSsVof1AAdGdOrlztGFQ gtLvZS0wOPmfbtSUn/Cacwj+7ds0Z2KP6W1fTKjw=
To: dnsop@ietf.org
References: <CAPt1N1nEH86yPvtoNqJ+xM-OFunEqr2x8s2LV_yFU1fkVt9WUQ@mail.gmail.com> <53074d98-a8ef-9127-edc7-d3e3188c2453@dougbarton.us> <CAPt1N1muo07jvDmyM+oL96Ow1RXGcsgVKX51S86CUcedirzvew@mail.gmail.com> <20180819.204841.532639858.sthaug@nethelp.no> <CAPt1N1nFW_h1i9cetKXm1isp9aUDKH73ZB+3trabFZd9NSDZkw@mail.gmail.com>
From: Doug Barton <dougb@dougbarton.us>
Message-ID: <40510317-dadc-7d93-543a-7da71fafd288@dougbarton.us>
Date: Sun, 19 Aug 2018 15:06:51 -0700
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1
MIME-Version: 1.0
In-Reply-To: <CAPt1N1nFW_h1i9cetKXm1isp9aUDKH73ZB+3trabFZd9NSDZkw@mail.gmail.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/5_bSqroVV4gjfNLLHN2hRRmJ2MI>
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: Sun, 19 Aug 2018 22:06:55 -0000

I agree with Steinar's sensibilities on this, FWIW.

Ted, you've restated your thesis several times now, but what I haven't 
seen is an answer to my question, so let me pose it a different way.

How is a user that relies on the DHCP server's DOH or DOT resolving name 
server instructions worse off than one who relies on the DHCP server's 
ordinary resolving name server instruction?

Also, we're not talking about introducing a new service here, we're 
talking about a configuration detail for a service that not only already 
exists, but is critical to get any real work done once you're on the 
network.

Doug

On 08/19/2018 12:28 PM, Ted Lemon wrote:
> I am indeed saying that when the IETF publishes a standards track 
> document with an applicability statement, the IETF is recommending that, 
> where applicable, the specification be used.
> 
> The problem with not deciding on the trust model is that it would be 
> impossible to write a clear applicability statement, and hence the 
> protocol would be implicitly applicable in all cases.   When you are 
> designing a protocol with very serious and significant trust 
> implications, this is a really bad idea.
> 
> Think about DHCP providing an SMTP server address.   Does that make 
> sense?   What is the trust model?   The IETF does indeed recommend this 
> for IPv4, but we didn't do it for IPv6 because we'd realized by the time 
> we did RFC 3315 that not every single thing you can in principle 
> configure with DHCP should be configured with DHCP.
> 
> 
> On Sun, Aug 19, 2018 at 2:48 PM, <sthaug@nethelp.no 
> <mailto:sthaug@nethelp.no>> wrote:
> 
>     > The DHCP solution is compatible only with trust relationship two.   So if
>     > the IETF were to recommend this way of configuring DoH and DoT, we would
>     > essentially be throwing away the privacy benefits of DoH and DoT (assuming
>     > that such benefits exist).
> 
>     I don't believe people are saying that the IETF should *recommend*
>     this way of configuring DoH and DoT - they're saying the DHCP option
>     should be *available*.
> 
>     Are you saying that all DHCP options introduced so far have been the
>     IETF recommended way of configuring things?
> 
>     Are you saying that no new DHCP option can be made available unless
>     the IETF recommends this way of configuring things?
> 
>     Both of these sound equally unreasonable/unlikely to me...
> 
>     Steinar Haug, AS2116
> 
>