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

Stephen Farrell <stephen.farrell@cs.tcd.ie> Mon, 25 September 2017 23:49 UTC

Return-Path: <stephen.farrell@cs.tcd.ie>
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 F0AC7134607; Mon, 25 Sep 2017 16:49:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.301
X-Spam-Level:
X-Spam-Status: No, score=-4.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cs.tcd.ie
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 Rxb-JPZlawC4; Mon, 25 Sep 2017 16:49:34 -0700 (PDT)
Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9155213460C; Mon, 25 Sep 2017 16:49:33 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 24E34BE2E; Tue, 26 Sep 2017 00:49:32 +0100 (IST)
X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie
Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HfRtiFE-6UQ0; Tue, 26 Sep 2017 00:49:30 +0100 (IST)
Received: from [10.244.2.100] (95-45-153-252-dynamic.agg2.phb.bdt-fng.eircom.net [95.45.153.252]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 768BEBE24; Tue, 26 Sep 2017 00:49:30 +0100 (IST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1506383370; bh=DU9Z6Bdu++1Oj6e+0YFLtdLvZ7me/OWBdQBE9YV2pJw=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=M1f75y5e79uOFD7+/S57eGzAXI3HYS95OjIsBfEt29bHcUKZgRDfinc2bhMhZxaLZ zY1utgpKeuysT3GhzNepulLb72WyXV0txPzhCFNhXCiuE6ZOVvGAWU29LoS+k4lEl3 9BSvyF1srsX+99X6dth3LK6cGOR4OfwigHKJsiCQ=
To: Adam Roach <adam@nostrum.com>
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> <06c81edd-9f11-616f-e549-06fb180564a4@nostrum.com>
From: Stephen Farrell <stephen.farrell@cs.tcd.ie>
Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url=
Message-ID: <09eeb83b-ca78-bcbc-386e-c87eb82064b7@cs.tcd.ie>
Date: Tue, 26 Sep 2017 00:49:29 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0
MIME-Version: 1.0
In-Reply-To: <06c81edd-9f11-616f-e549-06fb180564a4@nostrum.com>
Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="RlQdSXgmLoWMNsXCsuMp64JEV1CVPDh5A"
Archived-At: <https://mailarchive.ietf.org/arch/msg/doh/Wrg2rb89y06ouMr3qll3hwW7na0>
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:49:37 -0000

Hiya,

On 26/09/17 00:38, Adam Roach wrote:
> 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.

Again, it's a nit, but I've not clue what "not different" in the
above means. (Since DNSSEC is different:-)

> 
>>
>>> 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.
> 
> 

I'm fine with that. I'll be interested to see if others are
also.

> 
> 
>> 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.
> 

I'd be just about ok with that. My problems with your rephrasing
are:

- I'm not sure the WG can "ensure" a lack of adverse impact, so
  why make it a requirement, if it's not possible?

- Pollution of the OS's cache may not be the only bad thing that
  can happen, so that needs to be an example.

- I'm fine that a WG decide how to document stuff, but saying
  they can decide the manner in which such analysis is performed
  seems to me like you could drive a giant cart and horses-
  galore through that loophole, and that phrasing seems to
  nearly invite that, and I've seen WGs do just that kind of
  thing. I'd like that you or some other AD could ask to be
  pointed at the analysis results and for those to at minimum
  need a WG-list thread, so saying "do the work, document it
  however you like" seems like a better plan to me.

Cheers,
S.


> /a
> 
>