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

Ted Hardie <> Sat, 16 September 2017 17:33 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 358C413263F; Sat, 16 Sep 2017 10:33:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id wj1JhFXdwZF2; Sat, 16 Sep 2017 10:33:13 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:400d:c09::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 66F301321CB; Sat, 16 Sep 2017 10:33:13 -0700 (PDT)
Received: by with SMTP id u67so4405537qkg.6; Sat, 16 Sep 2017 10:33:13 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=p63N2iBtZSJISZRxo1UnBHOQkSpZezxUk2jl6lCYOzs=; b=hhjKSL/vBCWrDJIKTwUUfEFwFvBhOEWaYNxhSaTNONTXY+Cb376EbLEzj1wH5ZH/lU l7xX8JfMEmbBLrTat/rQxXbQHNnx9m9aLR+tr1Ja1Yw/JIJjtatfQCeLMPV5fnJtA6K6 BlA/+n9PkePDtmg2lRnk44ZVJ2RqNtoIrvIMpmlD0XOTml4z+ibio9z5dYkoLsIQJuwC xesn5klzYZI1WoRGg6JDRZu/+DmvitoaIr99lp9V1xAWQVUeO12hQSttccgeXpn8PdOV 5TLeQGApRkqDYvFOjr7HgEV7Pe5rsoZch9fjffsizJ9+A8EEMH/Y7UPuTnjEdlCQpwb2 BPIg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=p63N2iBtZSJISZRxo1UnBHOQkSpZezxUk2jl6lCYOzs=; b=NqCquPYXh2GOJITw/4eNrgEkUcJlBScMqf0qX/da0aTok1BGvzCy3KG+e7S5iTSiWL 8Pquq7uasr4Kt+oasi59u3Ya6WqNtnq18pReZhwy6P3yShiMECP3aqaDI+x+xIUdPlHj yuHTCv5PTuRQe+7c8F57667M/Bgfh4ysmkeN1F3Foad3ntHfEY/v6y3hSksiyozLvTgN RAUDQQo351P6hQKpAbJPk//vw96BPNsI/kPYA2hlbqm68bNepSge2DsN7wAyPlaWs1pC YaVjL78mfQLvwOpgrEvTy6lrECY3UzFuNtDJYxNOh3VGZ8Kj7IICMJlH+g5o9K6M94WT hw+g==
X-Gm-Message-State: AHPjjUhsXtoqMFACGwa0uGSfJAv4ikoBuwh7ZdEVRH9j+jUKVD3RGUYO e/fjVv7uO7dBXhayh5grquhjaTtfGXYjDXo6KYg=
X-Google-Smtp-Source: AOwi7QD6To+X7Nf4QBDkkY1aMcnAFifKBZAVHLTB4p38jokQQh98E046X/GVlDTMgvFlXDDw6gSrNbqqnNIql/xB7qQ=
X-Received: by with SMTP id w1mr13535542qkc.114.1505583192249; Sat, 16 Sep 2017 10:33:12 -0700 (PDT)
MIME-Version: 1.0
Received: by with HTTP; Sat, 16 Sep 2017 10:32:41 -0700 (PDT)
In-Reply-To: <>
References: <> <> <> <> <> <> <> <>
From: Ted Hardie <>
Date: Sat, 16 Sep 2017 10:32:41 -0700
Message-ID: <>
To: Mark Nottingham <>
Cc: Adam Roach <>,, Paul Hoffman <>, IETF <>
Content-Type: multipart/alternative; boundary="94eb2c063b485a99be055951e73e"
Archived-At: <>
Subject: Re: [Doh] WG Review: DNS Over HTTPS (doh)
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: DNS Over HTTPS <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sat, 16 Sep 2017 17:33:16 -0000

On Fri, Sep 15, 2017 at 6:52 PM, Mark Nottingham <> wrote:

> > On 16 Sep 2017, at 6:53 am, Ted Hardie <> 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 <> -- 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.  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.

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

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.