Re: [Doh] [Ext] A question of trust (was Re: Draft -09 and WGLC #2)

Sara Dickinson <sara@sinodun.com> Thu, 31 May 2018 09:21 UTC

Return-Path: <sara@sinodun.com>
X-Original-To: doh@ietfa.amsl.com
Delivered-To: doh@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C841612EC81 for <doh@ietfa.amsl.com>; Thu, 31 May 2018 02:21:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.199
X-Spam-Level:
X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 bSRfr8hkOSps for <doh@ietfa.amsl.com>; Thu, 31 May 2018 02:21:37 -0700 (PDT)
Received: from haggis.mythic-beasts.com (haggis.mythic-beasts.com [IPv6:2a00:1098:0:86:1000:0:2:1]) (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 3650F12EC34 for <doh@ietf.org>; Thu, 31 May 2018 02:21:37 -0700 (PDT)
Received: from [2001:b98:204:102:fffa::409] (port=57219) by haggis.mythic-beasts.com with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from <sara@sinodun.com>) id 1fOJlw-0004lL-UZ; Thu, 31 May 2018 10:21:34 +0100
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 11.3 \(3445.6.18\))
From: Sara Dickinson <sara@sinodun.com>
In-Reply-To: <197F1CB0-DFA5-4720-94E0-223D708B0D79@icann.org>
Date: Thu, 31 May 2018 10:20:34 +0100
Cc: Andrew Sullivan <ajs@anvilwalrusden.com>, "doh@ietf.org" <doh@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <3920ACC9-D167-4E2C-88E7-7A2AB317EA16@sinodun.com>
References: <382ba525100a4561b086fe8b8b6527be@ustx2ex-dag1mb3.msg.corp.akamai.com> <603D7553-D1A9-4DCC-9E74-199059C56A9F@sinodun.com> <1daad94d-99c1-803a-f52c-1dd17adefb7a@o2.pl> <CAOdDvNrpLwF5jpn1YA4-HXsfGxVkdds+xHVd6Bxy0Ux+3nrcrA@mail.gmail.com> <CA9BEE64-9F16-4CCC-A1E0-4C7FD45C455C@icann.org> <20180528161043.GB12038@mx4.yitter.info> <CABkgnnV3kKFCzKLfPf_0WZh95jr2vEt652Rb4EozfqROCVsJdA@mail.gmail.com> <CAOdDvNrPU9WM3WgcX1AVF39D3bGdxCKgPAF_afhfv2Qt0pZR5g@mail.gmail.com> <DB7D40D6-455A-48DD-AB98-DF2CF0866222@sinodun.com> <CAOdDvNopKvs18jQizgyiAQq8UyB4GwdqyXfXPa+25pNrxWg8pA@mail.gmail.com> <20180530143833.GB3110@mx4.yitter.info> <197F1CB0-DFA5-4720-94E0-223D708B0D79@icann.org>
To: Paul Hoffman <paul.hoffman@icann.org>
X-Mailer: Apple Mail (2.3445.6.18)
X-BlackCat-Spam-Score: 4
Archived-At: <https://mailarchive.ietf.org/arch/msg/doh/-TcqgzrIk2-sfCKd2AGsc9U8Lhw>
Subject: Re: [Doh] [Ext] A question of trust (was Re: Draft -09 and WGLC #2)
X-BeenThere: doh@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: DNS Over HTTPS <doh.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/doh>, <mailto:doh-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/doh/>
List-Post: <mailto:doh@ietf.org>
List-Help: <mailto:doh-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/doh>, <mailto:doh-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 31 May 2018 09:21:40 -0000


> On 30 May 2018, at 15:46, Paul Hoffman <paul.hoffman@icann.org> wrote:
> 
> On May 30, 2018, at 7:38 AM, Andrew Sullivan <ajs@anvilwalrusden.com> wrote:
>> 
>> Hi,
>> 
>> On Tue, May 29, 2018 at 09:22:54PM -0400, Patrick McManus wrote:
>>>   I support only specifying direct configuration in this document but either
>>>   way making it more explicit.
>>> 
>>> 
>>> I would describe [in]direct (or not) as one aspect of discovery, and the
>>> working group has chosen to stay away from discovery in this document.
>> 
>> To people who are used to the model of, "I got my resolver from DHCP,"
>> a thing you get from DHCP is not obviously "discovery".  It's
>> (auto)configuration.  It's not hard to see how a hotspot portal is
>> going to extend that metaphor using DOH, and it is still not clear to
>> me that this text is saying, "Don't do that," though I think it might
>> be.  
> 

I agree with Andrew here - the document doesn’t define either configuration or discovery and they are open to interpretation. A reader who has not been privy to the repeated discussions on the mailing list has no context within the document itself to accurately judge the distinction. If these terms were defined it would be easy to state what is in scope and what is out of scope and clarify the document further. If we as a WG struggle to define them then that in itself speaks to a lack of consensus on the problem statement.

I agree the new text is clearer about the push scenario but the general case of ‘configuration’ is still under specified IMHO.

Sara. 

> The new text from the pull request is hopefully clearer:
> 
> A DNS API client MUST NOT use a different URI simply because it was discovered
> outside of the client's configuration, or because a server offers an unsolicited response
> that appears to be a valid answer to a DNS query. This
> specification does not extend DNS resolution privileges to URIs that
> are not recognized by the DNS API client as configured URIs. Such
> scenarios may create additional operational, tracking, and security
> hazards that require limitations for safe usage. A future
> specification may support this use case.
> 
> That "future specification" might come out of DRIU, or from this WG.
> 
> --Paul Hoffman
> _______________________________________________
> Doh mailing list
> Doh@ietf.org
> https://www.ietf.org/mailman/listinfo/doh