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

Ted Hardie <ted.ietf@gmail.com> Wed, 20 September 2017 17:18 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 B3A9413303F; Wed, 20 Sep 2017 10:18:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 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] 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 nyAMx4NGrPoF; Wed, 20 Sep 2017 10:18:10 -0700 (PDT)
Received: from mail-qt0-x22d.google.com (mail-qt0-x22d.google.com [IPv6:2607:f8b0:400d:c0d::22d]) (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 B9C04133020; Wed, 20 Sep 2017 10:18:09 -0700 (PDT)
Received: by mail-qt0-x22d.google.com with SMTP id f15so3490912qtf.7; Wed, 20 Sep 2017 10:18:09 -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=iXr/Jsa/YABvqqXMuqlXkonDDwKdX1cWgp8rfxYYq2U=; b=I+eTB+auERzJJII/+oodozMp0QuFSzqaEX2pMlqnoW7MvGFwGuLZvDtSmnKyXxPWK5 Mi9/wq4s2HUSUd4gR/X/jRIS2IBH+vviahFcdmWAVht6gA1Td9i/Cegbvhb/ZNz/WCWW Nz1XFomZoZ56G2sM5rsYyQTjuXIskkpCTtFjVuoXNNIkgXe9O9eYROcr+4c220m6QNBl TtF0RqqHdWtv0uQ66U5Ic2xj8UOgg181uMcRdZfzb4veHwI19UrIc4734LKhRRC4RciI pHDzSxDspa0iCfS+3sAvmHi7Hv14I7H135HuXrtZUA3wle7TXLlsxpGYJNQ9RfRG2cZV VYXg==
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=iXr/Jsa/YABvqqXMuqlXkonDDwKdX1cWgp8rfxYYq2U=; b=kHpCHw8wATDIcX7UEoDplr6F4P46qiO8WPrGBNw/N9xQWBq/IiAgL7MUb4J/OF0zPn r2lR4rwiIcuKZxOo/1MiNpc3lgdx6c7fGFtSNwVpPMkatik64QEAJd/R9Ej/Jjqm5Dl/ 6mFbrF76O+zX7J5FsDF/SZ22s5TLkkRf9PRJJdu6ewRfv75Fd08vd+rEwxh8JK9mWlNq OXEP9W2xf/8QRjAsIA/uen+TFIv0SRAaPg3Dv5GQaYVHCp+D+W+fqIgdXPVQn1NvEn25 PRBG9r7vorOy6iOSx0EOPTeC3xtfsbLOseTKVZskLRPC1Oi65au1gvuKGKsB6bPq4ljM zj3w==
X-Gm-Message-State: AHPjjUjL8kPkJzrdEK4y1+eXTvbp0Wop7Jjx73+9rcqu7WVGoH3jRhgK WspoaqYgiOAyx/2GijA5OQuY92synQuMhIC5Rno=
X-Google-Smtp-Source: AOwi7QC5OEq5TdJJqlkckhqeWDrleJ9iqlxsCLO8X8qKZzNsikxXAgSyX9BRlGv1gOD9qLEz8q8A9jp/o7o9Ckfp/Q8=
X-Received: by 10.237.59.26 with SMTP id p26mr8815729qte.304.1505927888430; Wed, 20 Sep 2017 10:18:08 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.200.27.42 with HTTP; Wed, 20 Sep 2017 10:17:37 -0700 (PDT)
In-Reply-To: <296AD098-5728-44E6-855F-91881359162C@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> <32479A66-5D72-48CF-8C33-2D131AEB2B5B@mnot.net> <CA+9kkMCHPO_VO8sO2YUFLHCw8fTKFwoB4-Jy3V22ODHjtVs5YA@mail.gmail.com> <89896E61-3275-4214-BEC5-59D40B6DDA4A@mnot.net> <CA+9kkMC=C9cW6wabYApNv9svN0DTCaWTHCedYgzbELdwqSasuQ@mail.gmail.com> <296AD098-5728-44E6-855F-91881359162C@mnot.net>
From: Ted Hardie <ted.ietf@gmail.com>
Date: Wed, 20 Sep 2017 10:17:37 -0700
Message-ID: <CA+9kkMBwgT39PjbfxD-wGBy2JDMJYOSVHPte0uRqYYzus6N0fg@mail.gmail.com>
To: Mark Nottingham <mnot@mnot.net>
Cc: Adam Roach <adam@nostrum.com>, doh@ietf.org, Paul Hoffman <paul.hoffman@vpnc.org>, IETF <ietf@ietf.org>
Content-Type: multipart/alternative; boundary="94eb2c190786d8eb2a0559a228db"
Archived-At: <https://mailarchive.ietf.org/arch/msg/doh/2GevxpB68YC42epb2EvBDeTkvRw>
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: Wed, 20 Sep 2017 17:18:15 -0000

Howdy,

Comments in-line, with some snippage to help keep it readable.

On Wed, Sep 20, 2017 at 12:15 AM, Mark Nottingham <mnot@mnot.net> wrote:

>
> >> 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
> https://dns.initial-origin.example/query-for-dns?www.
> major-search-engine.example 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?
>
> No.
>
> The most you could do -- assuming when you say "JavaScript application"
> you mean Web page


Yes, I mean JavaScript application downloaded into a browser.


> (because JS can be run elsewhere, e.g., NodeJS; what's important is the
> constraints that the environment put upon it) -- is reuse that result
> within that page (and thanks to Service Worker, the origin as well, unless
> other pages opt out of SW), yes you can, today.
>
> Mind you, there's nothing special about the proposal on the table that
> makes it easier.
>
>
I have to disagree with this.  Standardizing this method should make this
easier by having a common format produced by servers and consumed by
clients.



> Also, doing so is pretty tortured for very limited gain; off the top of my
> head (handwave warning) you'd need to install a SW (or without it, create a
> bunch of event handlers in the page itself) to intercept requests, do your
> faux DNS, and then handle the response. This would work for embedded assets
> (e.g., JS, CSS, images) reasonably well on modern browsers,


So the scope of the problem is:  a malicious piece of JavaScript can embed
a DNS service into a web page such that some resources can be retrieved
using its resolution rather than the browser or system library.  It's not
clear how the user would determine that this was the case, so there is a
risk of mis-attribution within the web page.

That there is no intent to allow that information to be further propagated
is certainly useful to know, but if I understand you (and Adam) correctly,
this problem must be handled somewhere because of the intersection of this
proposal and JavaScript capabilities in a modern browser.

As a charter question, is the description of the problem and/or proposals
around it in scope for this proposed working group, or do we need to pass
th problem to someone else.  If someone else, who?


>
>
> >
> > 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.
>
> OK. If I read you correctly, you seem to be assuming that browsers (and
> other systems?) will somehow automatically handle responses that use a
> particular media type (or a specific URI scheme, or whatever) with elevated
> privileges (e.g., inserting them into the browser/OS DNS cache). I don't
> think this is part of the proposal. If someone has proposed that, please to
> point to the message so we can engage that idea.
>
>
I think you and I agree that if an OS or browser configuration frob
specifies a recursive resolver that uses DOH, that the results go where
ever they would have gone had the same information come in via UDP, TCP,
TLS, or DTLS.  From the information in this email, we agree that taking DNS
responses from a DOH recursive resolver specified in a download JavaScript
application would currently be limited to that application and those from
the same origin (and that building anything to take it further would be
unwise).  There's some work to do on how to handle misattribution within
that context, but it is not the same scope as the OS/browser configured
data.


> I think Adam and others believe that you *could* use this protocol from
> JavaScript (in a Web browser or otherwise) in a limited fashion (as
> outlined above), in that you would be bound by the security model of the
> environment you're working within. I don't think that is a major use case
> for this work, but it is a possible one.
>
> I don't think that anyone wants to establish new Web APIs to allow
> JavaScript to manipulate the browser/OS DNS resolution process or state. I
> certainly do not.
>
> Adam et al - If these statements aren't accurate, please say so.
>
> More to the point, the IETF is *not* the appropriate venue to be making
> core changes to the browser security model; at the very least, if we were
> doing that, we'd need to be coordinating *very* closely with the Web
> Application Security WG in the W3C.
>
> Should we be passing the charter by the Web Application Security WG in the
W3C now for comments?


> As above, defining this protocol won't change the capability of Web
> scripting by even the smallest amount. People do what they can today, and
> those capabilities will be the same after this is defined.
>
>
It will change the relationship of that Web scripting capability with the
DNS (or at least make that relationship much easier).  Given where the DNS
is in our stack, that's an important change.  If an attacker can take
information from an origin and have it treated as DNS data, it become the
foundation of retrievals from other origins.

To hideously over-simplify, the same origin security model presumes that
resources from an origin share a scope.  But if the origin is a recursive
resolver among other capabilities, the resources retrieved may provide data
about where to get other resources from outside that scope.

As long as there no APIs which push that data past the same origin
boundary, the problem with that is limited to misattribution within the
same origin.  But it is still a problem because of the role DNS info plays.



> >  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.
>
> It's not a matter of constraining the work; the work isn't proposing to
> operate even remotely in the way that you describe. I think we're just
> having a misunderstanding, because people have multiple use cases in mind
> for this protocol, and properties thereof have been mixed up.
>
>
AIUI those use cases are, roughly:
>
> 1. Configure your browser/OS to use a DOH service for DNS resolution (as
> above) -- this will affect browser/OS state, because it's being used for
> DNS; however, it's not being done from JS.
>
> Agreed, and I think this a very valuable piece of work to get done,
especially for the multiplexing properties of H2 or QUIC.



> 2. Call a DOH service from Javascript (for some reason) -- note this is
> just like any other HTTP request; it doesn't affect browser/OS state
> outside of the same origin model. Yes, you can still build a
> browser-in-a-browser and mess with things inside that context, but that's
> already true today.
>
>
While this is no doubt unintended, this tends to give a "everything is
already ruined" flavor to your response.  If we're standardizing this, I
think we need to take how this data is integrated and presented as part of
the overall deployment problem. If we're not the right folks to do that
part of the work, I think we need to get the right folks involved as soon
as possible and to put coordination with that community into the charter
along with DNSOP and the others already listed.

3. Future handwavy things like making DNS updates over HTTP -- very
> ill-defined and not important for this discussion
>
>
Yeah, I can't even tell from this whether you mean clients updating their
info a la DNS dynamic update  a la RFC 3007 or you mean push style updates
of fresh responses from a recursive resolver.  You can certainly leave the
first out.  Whether you can leave the second out or not depends on an
interaction between the HTTP caching model and the DNS caching model (That
is, if a configured DOH server pushes a new response to a query that hasn't
been asked yet, it would go into the HTTP cache in anticipation of the
question being asked.  When, though, that would get parsed and turned into
DNS data isn't clear to me.)

regards,

Ted