Re: [Doh] WG Review: DNS Over HTTPS (doh)

Adam Roach <adam@nostrum.com> Mon, 25 September 2017 23:38 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 554B91345FB; Mon, 25 Sep 2017 16:38:39 -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 2_VcE1QtttMo; Mon, 25 Sep 2017 16:38:38 -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 15255132355; Mon, 25 Sep 2017 16:38:38 -0700 (PDT)
Received: from Svantevit.roach.at (cpe-70-122-154-80.tx.res.rr.com [70.122.154.80]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id v8PNcVTF074661 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Mon, 25 Sep 2017 18:38:32 -0500 (CDT) (envelope-from adam@nostrum.com)
X-Authentication-Warning: raven.nostrum.com: Host cpe-70-122-154-80.tx.res.rr.com [70.122.154.80] claimed to be Svantevit.roach.at
To: Stephen Farrell <stephen.farrell@cs.tcd.ie>
Cc: Ted Hardie <ted.ietf@gmail.com>, doh@ietf.org, IETF <ietf@ietf.org>
References: <150549029332.2975.12341647131707994474.idtracker@ietfa.amsl.com> <CA+9kkMBJAP23GmGf_ix-DMeOMB=Rbas+qsBQhrVwZuA5-Cv7Mg@mail.gmail.com> <03b11478-6b75-8e52-e6d9-612885804aad@nostrum.com> <CA+9kkMA1z8XF7QNXdY_bGbHdUD8UOBS57VbbJn7xmt7rb8SOGw@mail.gmail.com> <2861b0eb-2486-9ba2-0b48-48293d758f03@cs.tcd.ie>
From: Adam Roach <adam@nostrum.com>
Message-ID: <06c81edd-9f11-616f-e549-06fb180564a4@nostrum.com>
Date: Mon, 25 Sep 2017 18:38:30 -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: <2861b0eb-2486-9ba2-0b48-48293d758f03@cs.tcd.ie>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: 8bit
Content-Language: en-US
Archived-At: <https://mailarchive.ietf.org/arch/msg/doh/02MAWIbXGRTTA4YDra_SGqD_fuo>
Subject: Re: [Doh] WG Review: DNS Over HTTPS (doh)
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: Mon, 25 Sep 2017 23:38:39 -0000

On 9/25/17 6:16 PM, Stephen Farrell wrote:
> A nit, a question and a comment:
>
> On 26/09/17 00:03, Ted Hardie wrote:
>> Adam,
>>
>> Thanks for summarizing the discussion and its outcomes.  Looking at the
>> revised charter, I noticed that it currently says "The use of HTTPS and its
>> existing PKI provides integrity and confidentiality, and it also allows the
>> transport to interoperate with common HTTPS infrastructure and policy."
> Nit: Not sure if it's worth nothing, but the integrity service here
> is different from DNSSEC, and clients need to be cognizant of that.
> Probably obvious though.

It's not different; it's in addition to. The mechanism being described 
would pass DNSSEC information through unscathed.

>
>> The choice not to specify a particular version means that there may be more
>> than one transport.  You may wish to rephrase this or elide it to reflect
>> the decision taken on that point.
> This para:
>
> "
> While access to DNS-over-HTTPS servers from JavaScript running
> in a typical web browser is not the primary use case for this
> work, precluding the ability to do so would require additional
> preventative design. The Working Group will not engage in such
> preventative design.
> "
>
> ... strikes me as weird, given that it didn't say what is the
> "primary" use-case. I think that needs fixing or may cause
> confusion later. The question is: did I miss where you said what
> was the primary use-case?

It's pretty similar to DPRIVE (or, really, DNS in general). I see that 
DPRIVE does have some text that seems to serve the purpose, so I'll copy 
it over with minor tweaks like so:

> The primary focus of this Working Group is to develop a mechanism that
> provides confidentiality and connectivity between DNS Clients and 
> Iterative
> Resolvers.  While access to DNS-over-HTTPS servers from JavaScript 
> running in
> a typical web browser is not the primary use case for this work, 
> precluding
> the ability to do so would require additional preventative design. The 
> Working
> Group will not engage in such preventative design.




> The comment: I find this version no better than the last in
> terms of saying that the WG needs to consider the scope within
> which DNS answers are used. And that was my major issue with
> the last iteration, so overall, this version doesn't seem that
> much better to me. My suggestion is to add text along these
> lines:
>
> "The WG will analyse the security and privacy issues that could
> arise from accessing DNS in this manner. For example it'd clearly
> be bad if JavaScript from random web sites could poison the OS's
> DNS cache (though hopefully no implementation would allow that).
> The manner in which that analysis is documented will be decided
> by the WG."

What I'm seeing here is that the IETF isn't going to propose any changes 
to the web security model. In most cases, I think this goes without 
saying; but since you and Ted have both raised the issue, I suppose it 
bears mention in the charter. I've tweaked your phrasing a bit:

> The Working Group will analyze the security and privacy issues that could
> arise from accessing DNS over HTTPS. In particular, the Working Group will
> ensure that access to DNS information from a JavaScript context will 
> not have
> adverse impact on the host operating system's DNS cache. The manner in 
> which
> such analysis is performed will be decided by the working group.

/a