Re: [Doh] Benoit Claise's No Objection on charter-ietf-doh-00-12: (with COMMENT)

Adam Roach <adam@nostrum.com> Thu, 28 September 2017 19:52 UTC

Return-Path: <adam@nostrum.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 6DC3E1348C9; Thu, 28 Sep 2017 12:52:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.88
X-Spam-Level:
X-Spam-Status: No, score=-1.88 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01] 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 SWD-EcaMql17; Thu, 28 Sep 2017 12:52:36 -0700 (PDT)
Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1F9661348D5; Thu, 28 Sep 2017 12:52:36 -0700 (PDT)
Received: from Svantevit.local (99-152-146-228.lightspeed.dllstx.sbcglobal.net [99.152.146.228]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id v8SJqUSj088611 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Thu, 28 Sep 2017 14:52:31 -0500 (CDT) (envelope-from adam@nostrum.com)
X-Authentication-Warning: raven.nostrum.com: Host 99-152-146-228.lightspeed.dllstx.sbcglobal.net [99.152.146.228] claimed to be Svantevit.local
To: Benoit Claise <bclaise@cisco.com>, The IESG <iesg@ietf.org>
Cc: doh@ietf.org, doh-chairs@ietf.org
References: <150659321397.13780.18221165528947192319.idtracker@ietfa.amsl.com>
From: Adam Roach <adam@nostrum.com>
Message-ID: <4cfa383f-deb3-6a13-6c63-218071454399@nostrum.com>
Date: Thu, 28 Sep 2017 14:52:25 -0500
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:52.0) Gecko/20100101 Thunderbird/52.3.0
MIME-Version: 1.0
In-Reply-To: <150659321397.13780.18221165528947192319.idtracker@ietfa.amsl.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Content-Language: en-US
Archived-At: <https://mailarchive.ietf.org/arch/msg/doh/wffCukR5Beb_MHE9NfBXt7Qr1_Q>
Subject: Re: [Doh] Benoit Claise's No Objection on charter-ietf-doh-00-12: (with COMMENT)
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, 28 Sep 2017 19:52:38 -0000

On 9/28/17 5:06 AM, Benoit Claise wrote:
> In my first ballot, I mentioned "What I've been failing to understand from the
> charter is the rational for DNS over HTTPS? Can you expand on this." Because
> I'm not an Web browser and DNS expert, or most likely because the concerns were
> not clear in my head, I could not clearly express my thoughts.
>
> So I watched the IETF mailing list with attention.
> Mark Nottingham's email summarized the situation
>
>      It's not a matter of constraining the work; the work isn't proposing to
>      operate even remotely in the way that you describe. I think we're just
>      having a misunderstanding, because people have multiple use cases in mind
>      for this protocol, and properties thereof have been mixed up.
>
>      AIUI those use cases are, roughly:
>
>      1. Configure your browser/OS to use a DOH service for DNS resolution (as
>      above) -- this will affect browser/OS state, because it's being used for
>      DNS; however, it's not being done from JS.
>
>      2. Call a DOH service from Javascript (for some reason) -- note this is
>      just like any other HTTP request; it doesn't affect browser/OS state
>      outside of the same origin model. Yes, you can still build a
>      browser-in-a-browser and mess with things inside that context, but that's
>      already true today.
>
>      3. Future handwavy things like making DNS updates over HTTP -- very
>      ill-defined and not important for this discussion
>
> Expressing #1 and #2 in the charter would have helped me. #2 is kind of present
> now. What about the addition the notion of "browser and/or OS" in the next
> sentence?
>
> The primary focus of this working group is to develop a mechanism that
> provides confidentiality and connectivity between DNS Clients and Iterative
> Resolvers.


I think "browser" is likely to confuse the issue, since people are 
likely to conflate that with JavaScript. Do you think it would be clear 
enough to say the following?

"The primary focus of this working group is to develop a mechanism that
provides confidentiality and connectivity between DNS Clients (e.g., 
operating
system stub resolvers) and Iterative Resolvers."

/a