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

Mark Nottingham <mnot@mnot.net> Sun, 17 September 2017 03:00 UTC

Return-Path: <mnot@mnot.net>
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 25AB113235A; Sat, 16 Sep 2017 20:00:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.72
X-Spam-Level:
X-Spam-Status: No, score=-2.72 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_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=mnot.net header.b=MCZe47+U; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=KM7AIHTa
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 36N7OdF092aW; Sat, 16 Sep 2017 20:00:17 -0700 (PDT)
Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 712AB1200F3; Sat, 16 Sep 2017 20:00:17 -0700 (PDT)
Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.nyi.internal (Postfix) with ESMTP id B04B3229CB; Sat, 16 Sep 2017 23:00:16 -0400 (EDT)
Received: from frontend1 ([10.202.2.160]) by compute3.internal (MEProxy); Sat, 16 Sep 2017 23:00:16 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mnot.net; h=cc :content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc:x-sasl-enc; s=fm1; bh=MHkLihSi1DlQy4RloW ZCHb1KazvL8dxnKfq6tQc29FU=; b=MCZe47+UZqrqhjh4kgv284Ng1c+TPwIG38 E7hiUD6LHnOqVnexzc4tzOCBODLEpIyOC3zYn9xKUfnZik3KPCuGKOsoPd24Jb9i vH3hQah0nWIxgX2f5SQAGTE5ViDPpAfDee1UAhGn243wfJ5afcYdDoTEBhckt2T4 LcQrYgURzs1AKf5WeFaJh3XbHPnJyRSfz2sQPlFE4mYIl2iAAaMYxMKs/wlsCE/b nIYkN0RwKkiJUeQIp4H7pqQ8vFnI9PGdjWZ+N2U7IcLzRIQQn6SoqG68d0BQO+D2 2fvwvIrIW6Hd/owBxEXJlJCezZzqMMJn+AFmZvemE4DWnnqM73Tg==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc:x-sasl-enc; s= fm1; bh=MHkLihSi1DlQy4RloWZCHb1KazvL8dxnKfq6tQc29FU=; b=KM7AIHTa wdMEMAWfX9pZSKGHzIkDcn8CytAuV6JePkckzzacVwn3OKtPNTMtVjyqVra0PqDd ztnxuZdVnGv1zFv7v5J8KxlHKcc4USwHbPUeGDTyZ5BXFKJ9PM02E5M4aMS6INDG JLoylZ9sKlR+URXo6d3H+qRiH4K7nfv8b2KER8ftsVQSzMpRzoqorEpYPA2wETo1 RxZg+7QmPDEo2IVukOlQ9JB16d/a62kk+w2uDwCFeox/dtXisitqsvyJYKjOhzpi 3mN1HGB4ZhcQyXShTQhnRgEULz478nO6YpWT1neVY/LPHWa2DTAuWk3wFXczi7Y0 dRSzTopK1Z/JPA==
X-ME-Sender: <xms:QOW9WRoZDj3iiZnMXajWJ8JnHbMiV117yzkGN9PNeuoELLu3x-AiFw>
X-Sasl-enc: ReVuDNhKy0tDFL/6Gn7M8RNADG58iKa6rUKmhRzzB9G3 1505617215
Received: from [192.168.1.14] (cpe-124-188-19-231.hdbq1.win.bigpond.net.au [124.188.19.231]) by mail.messagingengine.com (Postfix) with ESMTPA id 7D6B87E5EE; Sat, 16 Sep 2017 23:00:14 -0400 (EDT)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\))
From: Mark Nottingham <mnot@mnot.net>
In-Reply-To: <CA+9kkMDRdje0LTjAXLJkU6MeEP9tgJOmTjEP3jbtogyFtYYAwA@mail.gmail.com>
Date: Sun, 17 Sep 2017 13:00:11 +1000
Cc: Adam Roach <adam@nostrum.com>, doh@ietf.org, Paul Hoffman <paul.hoffman@vpnc.org>, IETF <ietf@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <32479A66-5D72-48CF-8C33-2D131AEB2B5B@mnot.net>
References: <150549029332.2975.12341647131707994474.idtracker@ietfa.amsl.com> <CA+9kkMBJAP23GmGf_ix-DMeOMB=Rbas+qsBQhrVwZuA5-Cv7Mg@mail.gmail.com> <EB3D58DB-1F8D-4E32-AE71-841EBCDDC3CA@vpnc.org> <42309404-8991-5d1d-7834-59087f273d41@nostrum.com> <CA+9kkMDokEDbBiCR_TRQda2RBHxoHag6mQL57Uzn7ALqakm1Og@mail.gmail.com> <e4a02fff-6803-28c7-c01d-f27a1b282d50@nostrum.com> <CA+9kkMCPRfjazW7Kk7GGnu1a0f2QNvgERV-5SGXWzp2HRmPJ=A@mail.gmail.com> <0EA5CC8C-D4B0-47F4-A8CF-950BDB1A1D55@mnot.net> <CA+9kkMDRdje0LTjAXLJkU6MeEP9tgJOmTjEP3jbtogyFtYYAwA@mail.gmail.com>
To: Ted Hardie <ted.ietf@gmail.com>
X-Mailer: Apple Mail (2.3273)
Archived-At: <https://mailarchive.ietf.org/arch/msg/doh/Gy0k9ed5hwR6vU1a46LZijOUgC4>
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: Sun, 17 Sep 2017 03:00:20 -0000

Ted,

On 17 Sep 2017, at 3:32 am, Ted Hardie <ted.ietf@gmail.com> wrote:
> 
> On Fri, Sep 15, 2017 at 6:52 PM, Mark Nottingham <mnot@mnot.net> wrote:
> 
>> > On 16 Sep 2017, at 6:53 am, Ted Hardie <ted.ietf@gmail.com> wrote:
>> >
>> > You're making an assumption that I don't think is established, that the requests using HTTPS for DNS are not distinguishable from other resources.  If they were keyed by something like dnsh://authority/query-target?RR (to pick on poor old RFC 4501 again), they would be in JavaScript *even if they were not on the wire*.
>> 
>> As before, I read the charter as saying that this protocol will use HTTP in the sense of <https://mnot.github.io/I-D/bcp56bis/#used> -- i.e., defining a new URI scheme is out of scope. If that's not clear, it should be made explicit.
> 
> 
> So, I don't that this is established.  One mental model for this work is that DNS, having started with UDP and TCP as transports, has now added a set of additional secure transports.  Two of those were defined in DPRIV; this defines another.  From that perspective, any time an application requires a DNS name to be resolved, the relevant local code would try the set of secure transports until it got an answer.  The application may not know which is used and does not specify it; it is simply getting the DNS answer back that allows it to proceed.  

Every time people start talking in this manner and referring to HTTP as a "transport", I get flashbacks to WS-* and what a glorious failure that was.

> The name of the group (DNS over HTTP), the justification at the beginning of the charter: 
> 
> This will enable the domain name system to function over certain paths where existing DNS methods (UDP, TLS, and DTLS) experience problems. This will enable the domain name system to function over certain paths where existing DNS methods (UDP, TLS, and DTLS) 
> experience problems. 
> 
> and Paul's input draft all point to that interpretation.  Note especially that Paul's draft provides the UDP wireformat as response.  To me, that strongly hints that the results of this get handed to the same bit of code that would take the UDP wireformat from other transports (like UDP) and do what it would have done with data retreived from any of those.  That behavior makes sense for DNS transported over HTTP, where you are talking to an authoritative server or shared resolver over a new transport.  

I don't disagree that the charter lays out that the goal is to enable the use case of DNS using HTTP semantics -- that's hopefully uncontroversial.

> That order of operations does not make sense as a new resource type available to web applications, in part because they can't tell from examining the URI whether the resulting *resource* obeys CORS or not.

It's not clear why that's an important property. Why is it necessary?

> There are serious attacks here that even DNSSEC won't catch, because a malicious server and cooperating JavaScript app could give correct answers that are non performant (like the search engine instance on the most distant continent).  

Who would be consuming these answers? How is this different from configuring your system to use a malicious DNS resolver (either in an application or the OS)?

> And, if there really was a handoff to the local DNS subsystem for parsing and processing, the JavaScript also wouldn't be able to tell whether the result they get from that subsystem is the one that the just retrieved (because a cache entry from some other system may have a different SOA record and be returned as a result instead).  To avoid that, they would have build udp wireformat parsers into the downloadable javascript.
> 
> I think if you want the second, a way of making DNS resources available to web applications, you need a very different approach; it may be valuable, but I don't believe this charter covers it.  If it is meant to, it needs a major re-write.

I agree there are significant risks when using DNS. I think the question is what to do about it.

One thing the WG could do would be to write some Security Considerations about the different ways this could be sub-optimal or even dangerous. 

I don't see how giving the protocol a new URI scheme avoids these risks, given that the defined resources would be available over HTTP still.

Cheers,

--
Mark Nottingham   https://www.mnot.net/