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

Ted Hardie <ted.ietf@gmail.com> Fri, 15 September 2017 19:25 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 F212B1341D3; Fri, 15 Sep 2017 12:25:52 -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 DRpcabueS-Xj; Fri, 15 Sep 2017 12:25:50 -0700 (PDT)
Received: from mail-qt0-x230.google.com (mail-qt0-x230.google.com [IPv6:2607:f8b0:400d:c0d::230]) (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 9BB7F1329F9; Fri, 15 Sep 2017 12:25:50 -0700 (PDT)
Received: by mail-qt0-x230.google.com with SMTP id q4so3071062qtq.8; Fri, 15 Sep 2017 12:25:50 -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=7wlaHoKHHbHRdmd+4rpgZKi5JIuhlGTYUH+m7pTmow0=; b=u/vofVC7OCDu2bqjBv60MUSkOI99cQVehd2Hi8gfN3rCW7kZJr/mkWpc55giNyapxs BoTc5WHAPd/ANRPDBZ1xNIrTQvVZnp/Op98Psh4NW0t5NY6xG3F3dn8C7Qb/aftEqNw2 GNWWMJ+VKbYydXw9HPONjECO3N4FOhFicAqmuD3U8CC19aYaolt8lWoHWRL6Mdl4T0vY DyccL1H1apXH8A7YoJxzGM+Rukq+J4rhLqp9bSIz4NCIDW6hPBpDReHq7mexJeoCqTHi qcRqlp2axI132WvWE0WSv50aatvlwTOFWdHpqTv0O7uXSzwczw/6zQkJWTSpx5GnMGRv LbAg==
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=7wlaHoKHHbHRdmd+4rpgZKi5JIuhlGTYUH+m7pTmow0=; b=ZhPQwgOqmX8kZnEZcCU9immLszH7Vd4FyvTVZJQrvSXtXldr4I/nAciKrflSdTREmD WKizPOyzXdOuM748EJoUbQzOUwstKkagq5mLJ73Y5pwOy1n020qSp1Nk3VyMsdBjMWt0 EQpzX8Xo4HoVs+//7i6iU5dpJI/RfwhNSp0aF7VUNIz+TwRvon4NiTlVHZvdYb87tOYP 3sG3Q4GC+DRcbmIp2zTYij09G5p5B+XMvbJmUyvtuYh5ZrQNzLHItfXsTSNqAjaEB3av S6V4FxcrRAOrtMTZEBxW72VIs+NM3in8pmktix4EZRD/EjZoyjMnW0IM3eQcWK0fkhpc 4hvA==
X-Gm-Message-State: AHPjjUig+0+4RZf/L5joxcmBOsaWznux9Hk6fU7UG8uwNhDT9kqTJRL2 5WPZ2LpvBFIpiZoGdjA/vzL/P6kg0X4prJujL1c=
X-Google-Smtp-Source: AOwi7QBENCB4rXfH8UdIOLl+PpzqfGLW5NHen6DUeCo0W+hCYQSlJX1U3wOdv3BpqyrRBh4vXnjGWVvdiXs4UK3eClI=
X-Received: by 10.237.53.86 with SMTP id b22mr39516630qte.33.1505503549456; Fri, 15 Sep 2017 12:25:49 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.200.27.42 with HTTP; Fri, 15 Sep 2017 12:25:19 -0700 (PDT)
In-Reply-To: <42309404-8991-5d1d-7834-59087f273d41@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>
From: Ted Hardie <ted.ietf@gmail.com>
Date: Fri, 15 Sep 2017 12:25:19 -0700
Message-ID: <CA+9kkMDokEDbBiCR_TRQda2RBHxoHag6mQL57Uzn7ALqakm1Og@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="001a11c01aac46078705593f5c72"
Archived-At: <https://mailarchive.ietf.org/arch/msg/doh/iSWwISvZq4BqNOBXme8Zwop2mKU>
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 19:25:53 -0000

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?


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

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?  If it is within same origin,
where does the resulting data go?  Just to the JavaScript or into browser
or system caches?

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 set of questions is pretty different from the ones you get with
"function over different paths", because the locus of control moves from
the mostly-trusted browser to the mostly not trusted downloaded application.


> This all bears more on the specified solution than the charter, but I
> suspect that (after a reasonable back-and-forth in the ensuing working
> group), one reasonable outcome will be that the mechanism works over HTTPS
> in general, simply because it will be too much of an implementation burden
> to prevent it from doing so.
>
> I'd rather not preclude the ability to have that discussion in the working
> group by foreclosing it in the charter language.
>
>
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.

regards,

Ted



> /a
>
>