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

Ted Hardie <> Tue, 19 September 2017 17:00 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 034EF133065; Tue, 19 Sep 2017 10:00:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.698
X-Spam-Status: No, score=-2.698 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, URIBL_BLOCKED=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 msSls5_0MVwG; Tue, 19 Sep 2017 10:00:21 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:400d:c09::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id CA38F13304E; Tue, 19 Sep 2017 10:00:20 -0700 (PDT)
Received: by with SMTP id o77so244249qke.9; Tue, 19 Sep 2017 10:00:20 -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=xAmGCggL0KaGwBqqZLifH04YnzaCC/+XZYbtIRraIFs=; b=RWHN6G9IbnXxNLKNsomdWpZAVpiDH0D09nxU/Em+aWPiRXIUbVcwKy4PJRgdtiy28t LuNq5PcrC1Qp8XufqoG0pqUB3wqyGp5/cc48trBWcLBaJcnbj/WGwzQgc1mX93qHMf4X 3txQ7g326MJkrjkpNyKoQ4+YJXU3fK+lqJzGtq3dYj3ufNpGjCMk+3vd/XevHFt9hoPV kPLHRnQy93wdMmJnwaeobdoDKE6BEfChwGAwQSJ6/T298JF/jp/z7In8p8Jcww7JzrU3 n47RJyv2/74iMby6yIJwpKIfIQnWpQ/SUP28x7guYtYn6qBeJ9toaNw0dLc4OOF1+Gi1 cUaQ==
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=xAmGCggL0KaGwBqqZLifH04YnzaCC/+XZYbtIRraIFs=; b=s6Q00WSYZX+U1R0DrMdLhzRd8ZkigNicSOO1lTnupAOs/QFaxIGcF4lo6fz4pPR1ue XHHeZ3HAuN87lZN23QLlrg3GS8cjQYxhiILbtJ1CRHgRo+UaprCdC1EsAtHu+asCtOHO KGArKlbapUjEa48TogfiM3EEPD5+3ePoSj6jv55tRpsS16i7qOUTP54BYioRbOkdsAb4 rn0Jk9hY2Ot5hX06EvRFzU1nikpZqOp6e1c42L1eIrAijVZ33zCY9t+R3xfDSHIww+Ic UHLIrCZCYCYmofVieZlwnDs96SsTdZU0oujBpkvohieCNEZNc1nFTK13QyBhi/ye3p1x suwA==
X-Gm-Message-State: AHPjjUjH6alrpm1OwmPzLmC7Yr00Huu5AENV42fOrXcditTick404GCt Dt4JrN8W6N5qwAohbQlSruAezYES8SdBAWxFdYU=
X-Google-Smtp-Source: AOwi7QCiLVeuX3+Fbh5519Wl8PzqCMgQL6h3LiAu9hFmDTWxrr8EUqV0WSXjhETvZRmjCyXsTH7dgquDkoDPfjuBBqE=
X-Received: by with SMTP id i63mr2731058qkc.19.1505840418219; Tue, 19 Sep 2017 10:00:18 -0700 (PDT)
MIME-Version: 1.0
Received: by with HTTP; Tue, 19 Sep 2017 09:59:47 -0700 (PDT)
In-Reply-To: <>
References: <> <> <> <> <> <> <> <> <> <> <> <>
From: Ted Hardie <>
Date: Tue, 19 Sep 2017 09:59:47 -0700
Message-ID: <>
To: Mark Nottingham <>
Cc: Adam Roach <>,, Paul Hoffman <>, IETF <>
Content-Type: multipart/alternative; boundary="94eb2c05c2a63785b005598dcb09"
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: Tue, 19 Sep 2017 17:00:24 -0000


I'll try to snip pieces not salient without hindering attribution; hope
that helps.

On Mon, Sep 18, 2017 at 5:26 PM, Mark Nottingham <> wrote:

> Hi Ted,
> Sorry, threading is a bit confusing below (thanks, GMail).
> > On 19 Sep 2017, at 3:20 am, Ted Hardie <> wrote:
> >
> > On Sat, Sep 16, 2017 at 8:00 PM, Mark Nottingham <> wrote:
> >
> > If it helps, I am happy to say "facilitating protocol".  The mental
> model question for the charter is really:
> >
> > Does this add a new tool for DNS systems attempting resolution to use
> when previous efforts are blocked?  So any DNS resolution might use it,
> whether from a browser, an app, or system call, but that those would not
> *specify* it be used?
> That sounds like an implementation choice, not a protocol decision. What
> in the protocol could constrain that?
I'm talking about the goals here.  If the intent is to have this
facilitating protocol hot-swappable for any other method of interacting
between a DNS client and DNS server, we have a set of tasks in front of the
working group and a good idea of where the trade-offs should lean.

> > Does this add a method for Web application to directly resolve DNS
> resource records
> Well, once it's available over HTTP, that's certainly possible. A quick
> search for "DNS lookup online" shows many people doing that already, albeit
> with different formats.
> > using a resolver self-identified in the Javascript? So DNS resolutions
> are instantiated and consumed by Javascript without any intermediation by
> the local DNS resolver or the browser's DNS rules?
> What does "a resolver self-identified in the Javascript" mean, exactly?
> Are you supposing some sort of rendezvous system where I can "install" a
> DOH resolver from one origin and have it affect requests sent to another?
Can I have JavaScript retrieve a resource like
then use the result in place of the browser's DNS routines or the system
DNS routines for retrieving https://www.major-search-engine.example/ within
that JavaScrit application?  If that is possible, then I need to know where
the DNS data retrieved can be reused and I need to know whether the
rendering distinguishes in any way between data so retrieved and data
retrieved by a more trusted element.   Does the data end up in the
browser's DNS cache?  Does a hover over an element show that this URI would
be using a JavaScript supplied resolver to retrieve the location should I

> Doing so isn't possible on the current Web, so enabling it would require
> some fairly heavy lifting at the W3C and/or WHATWG (which on the face of
> it, they're not likely to think is sane). I can only hope that defining
> such a thing is out of scope for this WG, as we truly don't have the
> expertise here.
Interestingly, that's not what I understood others' answer to be.  Their
view was that since
was within the initial-origin, resources from it would be treated as same
origin.  If I understood correctly the code that would limit those
resources to same origin isn't present and would have to run after the UDP
wireformat was parsed (otherwise there are trivial attacks in returning
additional data that cache poisons whatever the scope of use turns out to

> > Does this charter aim for the working group to do both?
> >
> > As currently written, I see the charter describing 1.  There has been an
> argument that it also do 2 or that 2 becomes possible when 1 is specified
> and is thus automatically part of the scope.  If that is the case, I
> believe the charter needs a re-write to describe it.
> See above.
> >
> > > 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?
> >
> >
> > If it goes into a browser or system cache, it is an important property;
> it may also be important depending on the UI result.  If the
> JavaScript-internal resolution process feeds other parts of the page, it
> may even be a problem.
> When you say "cache", do you mean HTTP or DNS? I'm afraid I still don't
> get what you're looking for here.
I mean DNS cache.  My apologies for the earlier inexactness.

> >  > 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)?
> >
> > Because the JavaScript you download could pick the resolver.  The OS and
> browser are largely trusted; the JavaScript is largely not.
> OK, this seems to indicate you *do* think that somehow arbitrary JS can
> take over DNS resolution for the system or browser. What led you to that
> conclusion?
The goal to use this as a swappable facilitating protocol for DNS
resolution led me to that conclusion; in that usage, the resulting DNS data
would populate the relevant DNS cache.  Re-using the same system within
JavaScript naively would have very bad properties; some segregation to
handle the different levels of trust is required.

> >
> >  I don't know that browsers want to do that, mind you, I'm simple saying
> that the working group could decide that this was a reasonable facility to
> consider.  Ruling out ways for the ecosystem to distinguish this from other
> web resources seems to be the wrong way to go, at least to me.
> Again, I don't think this WG should be attempting to allow any sort of
> automated control of browser or system DNS resolution from the Web (e.g.,
> JS, triggered by arbitrary URI schemes, mime types, whatever); I've seen
> zero desire from any implementer to allow that, it's fraught with security,
> privacy and other issues, and has dubious benefit.
> Should I take it that you disagree with the assertion that if we build for
goal 1 (a swappable facilitating protocol) that we have automatically built
a mechanism that is callable within a JavaScript application (which, as I
understand it, Adam and others believe)?

> The use case that I believe most have in mind is "as a user, I want to
> configure my [browser, OS] to use *this* DOH service for DNS resolution" --
> where that configuration is manual; e.g., a configuration textbox or
> dropdown in the browser, or a file in /etc. It might be made more
> user-friendly; e.g., it could be automatic when the user goes into the
> ill-defined "private mode."
Would you consider a system in which the local browser or OS tested for the
availability of a DOH server at a supplied address within scope (that would
be one way to re-use the current DHCP-supplied servers, for example)?

The current charter allows that. I *think* the issues you're concerned
> about are in a very different area -- roughly, "automated control of DNS
> resolution." I'm not sure where you got the sense that this was on the
> table, but if it will help, write it out of the charter.
> My concern isn't just that it be out of scope of the charter, its that it
either be not in the capability set of the resulting work or well-handled
in that context.  Folks asserting that it could not be eliminated from the
capability set for JavaScript applications caused me to focus on the
latter.  If the work can be constrained such that this does not arise, so
much the better.



> Cheers,
> --
> Mark Nottingham