Re: [Doh] WG Review: DNS Over HTTPS (doh)
Ted Hardie <ted.ietf@gmail.com> Fri, 15 September 2017 20:54 UTC
Return-Path: <ted.ietf@gmail.com>
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 225DD134213; Fri, 15 Sep 2017 13:54:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level:
X-Spam-Status: No, score=-1.998 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_NONE=-0.0001, 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=gmail.com
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 wA-Hfx93VsyA; Fri, 15 Sep 2017 13:54:13 -0700 (PDT)
Received: from mail-qt0-x22b.google.com (mail-qt0-x22b.google.com [IPv6:2607:f8b0:400d:c0d::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1292B126E64; Fri, 15 Sep 2017 13:54:13 -0700 (PDT)
Received: by mail-qt0-x22b.google.com with SMTP id m35so3292791qte.1; Fri, 15 Sep 2017 13:54:13 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=AK6M4Wzz8yK0kBWMkSQ2uN4LIrNgN7pIPlFxywceCw0=; b=FSNHdXLDFzABfS2mKZESN0hC2lhxRGR8vW11HjvnN7mp4JldMqUdWV2AhjrvMfBlID layIsZWiqFyOxznJlYazrc6MaxpDXJEidi/4hjaJXD8vPaqVosURY8x7PNCmP3zqI+Ws Ejy9hmzuZmbXFyptCo+tzKmWheOQoOTr7kVP/uSeVW4DmhpEHAwPUNbeD/xAaA6FaoYA gRbXLR6VpxQZ9+nsiQRIQJprECdpJoVK2s31Npphl+ltNAtzh6wGbi/6X89L9l4BIL+b 2IE+R17zuhJkRI5wKXNlOdNfTu77SBi5cNXYOJg5SwEt7GdH8NL+1Nn7hmRMIj66maQ1 SlpQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=AK6M4Wzz8yK0kBWMkSQ2uN4LIrNgN7pIPlFxywceCw0=; b=SFGqMrXRuaf5Gshgm3ZrcuXyHrWM1vBL8wUTrMvFn6EFit1fVGIGr1337wFoBanlLU E0kP7tb35/rSuc6aSnNEwh/qgj3QSkms1rSrFSB8MDN1XCwstIRVLmImwL1oasH8dchm j/F5jyorzidknSKOiH+8RJl40swMXpOsGJqw9zl0vdXXnjI95AcfQturzJvr8k4eRQx0 6cqOHJTAQ1scM0tTjRDHm2pOhrH4pqp6KJBfCzf6Rz4OqJVJmEc5svCVC81iLqcoOiJ7 1hQA6ZMn09xmHlin2p1JBqbshVyzUE2HNCGzZ4ej4G76Z1igohV68HJRUhL1xexdcp/w vY6A==
X-Gm-Message-State: AHPjjUg1yTYkgXIiJvAVkuGPk5lrHoyO4g85g+LHWOAY7PViMd98OL3a pxcsslUw28plSC2PZsI/R6UoyAGh0RoWh7BCTig=
X-Google-Smtp-Source: AOwi7QCwu+HLTOJRCyjWnkl2RVDm8NFGT2d0UAEne/n7GMGEJNARdT+G0gCvnfrFvJW0OhoXody2Stby2DPaREFzf14=
X-Received: by 10.237.37.231 with SMTP id y36mr39042634qtc.199.1505508850844; Fri, 15 Sep 2017 13:54:10 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.200.27.42 with HTTP; Fri, 15 Sep 2017 13:53:40 -0700 (PDT)
In-Reply-To: <e4a02fff-6803-28c7-c01d-f27a1b282d50@nostrum.com>
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>
From: Ted Hardie <ted.ietf@gmail.com>
Date: Fri, 15 Sep 2017 13:53:40 -0700
Message-ID: <CA+9kkMCPRfjazW7Kk7GGnu1a0f2QNvgERV-5SGXWzp2HRmPJ=A@mail.gmail.com>
To: Adam Roach <adam@nostrum.com>
Cc: Paul Hoffman <paul.hoffman@vpnc.org>, doh@ietf.org, IETF <ietf@ietf.org>
Content-Type: multipart/alternative; boundary="001a114029b642cc37055940981c"
Archived-At: <https://mailarchive.ietf.org/arch/msg/doh/24aJjb2fEDWc9uB58M2N3spFRHk>
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: Fri, 15 Sep 2017 20:54:16 -0000
In-line. On Fri, Sep 15, 2017 at 1:19 PM, Adam Roach <adam@nostrum.com> wrote: > On 9/15/17 14:25, Ted Hardie wrote: > > On Fri, Sep 15, 2017 at 12:00 PM, Adam Roach <adam@nostrum.com> 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. > > 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*. > 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 https://dns.fb.com/www.google.com?type=AAAA, > will that be within same origin policy or not? > > > You didn't say what the origin of the calling page was. > Sorry, when I said "Facebook JavaScript" I meant to imply that facebook was the origin and that fb.com would same origin. > If it's the same origin, then it's the same origin (modulo CORS behavior). > > I'm frankly a bit worried that the GET version of Paul's draft would not trigger the CORS pre-flight checks. If it is consumed by JavaScript and never otherwise cached, that's not so big a deal, but if it is populating a browser or system cache, it's a problem. > 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. > > I'm not sure "no special browser behavior" answers my question. Is the default the browser behavior when it gets a DNS response or the browser behavior for content JavaScript requests in-line? > In addition to same origin questions, there are some privacy issues around > this being used to signal external parties. Imagine a query like this: > > https://dns.google.com/unique-id.partner-site.com?type=TXT > > 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 8.8.8.8 and 8.8.4.4 > handle it. I suppose the API deployed at https://developers.google.com/ > speed/public-dns/docs/dns-over-https is probably closer to the use case > we're contemplating, though. > > (I wasn't involved developing that, so the view from the outside); that looks very much like it would take the JSON records returned and populate the standard cache(s) with them. 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. > > The trust relationship you mention is important (the JavaScript trusting its source), but we also have to consider the user's trust in the JavaScript. A malicious piece of JavaScript is not so hard to introduce into the world, and if it can influence the DNS mapping, it may be well worth the time of phishers and others to do so. 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." > I assume that you have code that would let you say "not unless protected by TLS", though, so that portion of the charter presumption matches reality? Thanks for your insight into this, Ted > > /a >
- Re: [Doh] WG Review: DNS Over HTTPS (doh) Cullen Jennings
- Re: [Doh] WG Review: DNS Over HTTPS (doh) Eliot Lear
- [Doh] WG Review: DNS Over HTTPS (doh) The IESG
- Re: [Doh] WG Review: DNS Over HTTPS (doh) Paul Hoffman
- Re: [Doh] WG Review: DNS Over HTTPS (doh) Adam Roach
- Re: [Doh] WG Review: DNS Over HTTPS (doh) Ted Hardie
- Re: [Doh] WG Review: DNS Over HTTPS (doh) Adam Roach
- Re: [Doh] WG Review: DNS Over HTTPS (doh) Ted Hardie
- Re: [Doh] WG Review: DNS Over HTTPS (doh) Adam Roach
- Re: [Doh] WG Review: DNS Over HTTPS (doh) Paul Hoffman
- Re: [Doh] WG Review: DNS Over HTTPS (doh) Spencer Dawkins at IETF
- Re: [Doh] WG Review: DNS Over HTTPS (doh) Stephen Farrell
- Re: [Doh] WG Review: DNS Over HTTPS (doh) Stephen Farrell
- Re: [Doh] WG Review: DNS Over HTTPS (doh) Mark Nottingham
- Re: [Doh] WG Review: DNS Over HTTPS (doh) Mark Nottingham
- Re: [Doh] WG Review: DNS Over HTTPS (doh) Patrick McManus
- Re: [Doh] WG Review: DNS Over HTTPS (doh) Stephen Farrell
- Re: [Doh] WG Review: DNS Over HTTPS (doh) Ted Hardie
- Re: [Doh] WG Review: DNS Over HTTPS (doh) Adam Roach
- Re: [Doh] WG Review: DNS Over HTTPS (doh) Mark Nottingham
- Re: [Doh] WG Review: DNS Over HTTPS (doh) Phillip Hallam-Baker
- Re: [Doh] WG Review: DNS Over HTTPS (doh) Tim Wicinski
- Re: [Doh] WG Review: DNS Over HTTPS (doh) Ted Hardie
- Re: [Doh] [Ext] WG Review: DNS Over HTTPS (doh) Paul Hoffman
- Re: [Doh] [Ext] WG Review: DNS Over HTTPS (doh) Adam Roach
- Re: [Doh] [Ext] WG Review: DNS Over HTTPS (doh) Paul Hoffman
- Re: [Doh] WG Review: DNS Over HTTPS (doh) Mark Nottingham
- Re: [Doh] WG Review: DNS Over HTTPS (doh) Eliot Lear
- Re: [Doh] WG Review: DNS Over HTTPS (doh) Ted Hardie
- Re: [Doh] WG Review: DNS Over HTTPS (doh) Adam Roach
- Re: [Doh] WG Review: DNS Over HTTPS (doh) Mark Nottingham
- Re: [Doh] WG Review: DNS Over HTTPS (doh) Ted Hardie
- Re: [Doh] WG Review: DNS Over HTTPS (doh) Adam Roach
- Re: [Doh] WG Review: DNS Over HTTPS (doh) Mark Nottingham
- Re: [Doh] WG Review: DNS Over HTTPS (doh) Adam Roach
- Re: [Doh] WG Review: DNS Over HTTPS (doh) Adam Roach
- Re: [Doh] WG Review: DNS Over HTTPS (doh) Phillip Hallam-Baker
- Re: [Doh] WG Review: DNS Over HTTPS (doh) Eliot Lear
- Re: [Doh] WG Review: DNS Over HTTPS (doh) Adam Roach
- Re: [Doh] WG Review: DNS Over HTTPS (doh) Ask Bjørn Hansen
- Re: [Doh] WG Review: DNS Over HTTPS (doh) Ask Bjørn Hansen
- Re: [Doh] WG Review: DNS Over HTTPS (doh) Adam Roach
- Re: [Doh] WG Review: DNS Over HTTPS (doh) Eliot Lear
- Re: [Doh] WG Review: DNS Over HTTPS (doh) Mark Nottingham
- Re: [Doh] WG Review: DNS Over HTTPS (doh) Eliot Lear
- Re: [Doh] WG Review: DNS Over HTTPS (doh) Magnus Westerlund
- Re: [Doh] WG Review: DNS Over HTTPS (doh) Ted Hardie
- Re: [Doh] WG Review: DNS Over HTTPS (doh) Phillip Hallam-Baker
- Re: [Doh] WG Review: DNS Over HTTPS (doh) Mark Nottingham
- Re: [Doh] WG Review: DNS Over HTTPS (doh) Eliot Lear
- Re: [Doh] WG Review: DNS Over HTTPS (doh) Toerless Eckert
- Re: [Doh] WG Review: DNS Over HTTPS (doh) Toerless Eckert
- Re: [Doh] WG Review: DNS Over HTTPS (doh) Toerless Eckert
- Re: [Doh] WG Review: DNS Over HTTPS (doh) Tony Finch
- Re: [Doh] WG Review: DNS Over HTTPS (doh) Phillip Hallam-Baker
- Re: [Doh] WG Review: DNS Over HTTPS (doh) Patrick McManus
- Re: [Doh] WG Review: DNS Over HTTPS (doh) Eliot Lear
- Re: [Doh] WG Review: DNS Over HTTPS (doh) Warren Kumari
- Re: [Doh] WG Review: DNS Over HTTPS (doh) Warren Kumari
- Re: [Doh] WG Review: DNS Over HTTPS (doh) Martin Thomson
- Re: [Doh] WG Review: DNS Over HTTPS (doh) Adam Roach
- Re: [Doh] WG Review: DNS Over HTTPS (doh) Ted Hardie
- Re: [Doh] WG Review: DNS Over HTTPS (doh) Adam Roach
- Re: [Doh] WG Review: DNS Over HTTPS (doh) Stephen Farrell
- Re: [Doh] WG Review: DNS Over HTTPS (doh) Adam Roach
- Re: [Doh] WG Review: DNS Over HTTPS (doh) Stephen Farrell
- Re: [Doh] WG Review: DNS Over HTTPS (doh) Martin Thomson
- Re: [Doh] WG Review: DNS Over HTTPS (doh) Stephen Farrell
- Re: [Doh] WG Review: DNS Over HTTPS (doh) Adam Roach
- Re: [Doh] WG Review: DNS Over HTTPS (doh) Patrick McManus