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

Adam Roach <> Fri, 15 September 2017 20:19 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id C3CD4133074; Fri, 15 Sep 2017 13:19:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.878
X-Spam-Status: No, score=-1.878 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id bcZyBNe-fjMC; Fri, 15 Sep 2017 13:19:51 -0700 (PDT)
Received: from ( [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 5CF591341F8; Fri, 15 Sep 2017 13:19:51 -0700 (PDT)
Received: from Orochi.local ( []) (authenticated bits=0) by (8.15.2/8.15.2) with ESMTPSA id v8FKJmS3079529 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Fri, 15 Sep 2017 15:19:49 -0500 (CDT) (envelope-from
X-Authentication-Warning: Host [] claimed to be Orochi.local
To: Ted Hardie <>
Cc: Paul Hoffman <>,, IETF <>
References: <> <> <> <> <>
From: Adam Roach <>
Message-ID: <>
Date: Fri, 15 Sep 2017 15:19:43 -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: <>
Content-Type: multipart/alternative; boundary="------------1CDEA10D0626F2D160C651CB"
Content-Language: en-US
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: Fri, 15 Sep 2017 20:19:54 -0000

On 9/15/17 14:25, Ted Hardie wrote:
> On Fri, Sep 15, 2017 at 12:00 PM, Adam Roach < 
> <>> wrote:
>     On 9/15/17 1:24 PM, Paul Hoffman wrote:
>         Yes, please. The charter should say "HTTP/2 over TLS". There
>         is no reason for current browsers adding this feature to add
>         it using an obsolete protocol.
>     I think you're assuming a tighter coupling between layers than
>     actually exists.
>     In particular -- since you're talking about browsers -- it would
>     easy to implement the current draft entirely in content
>     JavaScript. In doing so, it would be impossible for the
>     implementation to prevent its use over HTTP/1.1 (or QUIC): aside
>     from some proprietary browser-specific APIs,
> So, "the implementation" in your statement above--is that the 
> JavaScript or the browser?

In the scenario I'm describing, it's the JavaScript.

>     there's no way for such an implementation to even tell what
>     version of HTTP is in use, much less prevent certain queries from
>     going out over unwanted ones.
> So, I think you have a usage in mind that is not the usage model that 
> the draft talks about and is not really clear in the charter--the use 
> of this within a JavaScript application to collect DNS responses 
> without going through the browser/OS cache and DNS method.  If that is 
> a proposed use case, then I think there is a serious question of how 
> the same origin policy applies here.

Given that (in this scenario), the browser wouldn't know this query from 
any _other_ HTTPS request, it applies the same way as it does to all 
other HTTPS requests.

> Assume for a second that the resource in question mimics the current 
> DNS URI structure (RFC 4501), but substitutes HTTPS as a scheme.   If 
> Facebook JavaScript has a call for 
>, will that be within same 
> origin policy or not?

You didn't say what the origin of the calling page was. If it's the same 
origin, then it's the same origin (modulo CORS behavior).

> If it is within same origin, where does the resulting data go?  Just 
> to the JavaScript or into browser or system caches?

The scenario I'm posting above assumes no special browser behavior.

> In addition to same origin questions, there are some privacy issues 
> around this being used to signal external parties.  Imagine a query 
> like this:
> I don't know of any cross-site cookie watcher that would catch that, 
> but it might be needed.

This is a fine point. I do wonder how the resolvers at and handle it. I suppose the API deployed at is 
probably closer to the use case we're contemplating, though.

To be clear, I'm not saying that these situations you describe aren't 
_bad_; I'm pointing out that they already exist with or without the 
mechanism under discussion. I would think the standard here is "don't 
make it worse," rather than "first, drain the swamp."

I'll also point out that this use case (the JavaScript-based one) is 
nice in that it allows applications to communicate with a known trusted 
site (e.g., their own origin) to prevent this kind of unintentional 
exfiltration of information. Of course, this is already possible today 
using proprietary mechanisms, but it would be nice if such apps could 
use standard libraries.

> I agree that the working group has to tackle it if it is in scope.  
> The question we're discussing now is whether that use case is in 
> scope.  If any potential solution must deal with that eventuality 
> because they all *could* be done in Javascript, like it or not, then 
> the question is moot, but that's not personally clear to me yet.

I chose that example because it's easy to reason about without knowing 
the internal implementation architecture of browsers. If we instead turn 
to the *other* use case that you describe in which the browser (absent 
any special JavaScript handling) chooses to use DNS-over-HTTPS, then a 
congruent problem arises. While it's not an area I've worked in closely, 
what I've seen of Firefox's network layer implementation leads me to 
believe that precluding a mechanism like this from working across all 
supported variations of HTTP would require additional code; and that the 
role of that code, in its entirety, would be to prevent from working 
that which otherwise would. Unless there are, say, security implications 
to doing so, I'd think we need better rationale for preventing it than 
"we don't want to think about it."