Re: [dispatch] New proposed work: DNS over HTTPS

Stephen Farrell <stephen.farrell@cs.tcd.ie> Sat, 17 June 2017 12:33 UTC

Return-Path: <stephen.farrell@cs.tcd.ie>
X-Original-To: dispatch@ietfa.amsl.com
Delivered-To: dispatch@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5CDD7129485 for <dispatch@ietfa.amsl.com>; Sat, 17 Jun 2017 05:33:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.301
X-Spam-Level:
X-Spam-Status: No, score=-4.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cs.tcd.ie
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 uNuO4IrLwEH6 for <dispatch@ietfa.amsl.com>; Sat, 17 Jun 2017 05:33:35 -0700 (PDT)
Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 497E912949A for <dispatch@ietf.org>; Sat, 17 Jun 2017 05:33:35 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 76298BE3E; Sat, 17 Jun 2017 13:33:33 +0100 (IST)
X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie
Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U8zI34-Wn2Mw; Sat, 17 Jun 2017 13:33:31 +0100 (IST)
Received: from [10.244.2.100] (95-45-153-252-dynamic.agg2.phb.bdt-fng.eircom.net [95.45.153.252]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 16F18BE39; Sat, 17 Jun 2017 13:33:31 +0100 (IST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1497702811; bh=6BAXW0HEC24ck0L5as68pDqu+rX+XUERuyZP17iBEaU=; h=Subject:To:References:From:Date:In-Reply-To:From; b=viAAqt/+w7QTQp6Bz+xy7TLLTIXS02LBEkCKclMnizxF1Uco3c+xfUVs5lzqw80ts FPA703ieuTFlKwe210wZ5tasbQTDC4gPSG1/mROTvJ34C9xEmM/Ai0bZgyzC8WDWmt 3UKcyltxiI1PbUxe/fqTzhjGm5swpnPOXtKOe3os=
To: Paul Hoffman <paul.hoffman@icann.org>, "dispatch@ietf.org" <dispatch@ietf.org>
References: <52CA02A7-705D-4D5E-AC1D-FB0B02BB4305@icann.org>
From: Stephen Farrell <stephen.farrell@cs.tcd.ie>
Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url=
Message-ID: <c47ec331-fabd-a8ae-45d4-2eda5ed482c6@cs.tcd.ie>
Date: Sat, 17 Jun 2017 13:33:30 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.1.1
MIME-Version: 1.0
In-Reply-To: <52CA02A7-705D-4D5E-AC1D-FB0B02BB4305@icann.org>
Content-Type: multipart/signed; micalg="pgp-sha256"; protocol="application/pgp-signature"; boundary="BTrd65sNVwcUIrOIeNevDdNlgkuxk4J4N"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dispatch/NMGrSmH6gaWc2hgZcg6_aNftaSM>
Subject: Re: [dispatch] New proposed work: DNS over HTTPS
X-BeenThere: dispatch@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: DISPATCH Working Group Mail List <dispatch.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dispatch>, <mailto:dispatch-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dispatch/>
List-Post: <mailto:dispatch@ietf.org>
List-Help: <mailto:dispatch-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 17 Jun 2017 12:33:38 -0000

FWIW I generally support this work.

Despite the last para of the security considerations section
(which may be partly in response to some off list comments I
made, and if so thanks:-), I think more effort needs to be
devoted to considering attacks that might use this. For example,
it may be that it'd be sensible to explore whether or not a browser
using this mechanism ought limit the DNS cache resulting to
the tab that is rendering content from that origin or something.
And yes, current browsers may be equally vulnerable to similar
attacks via WiFi APs, but there remain differences - e.g., folks
probably only regularly interact with a few APs, but with many
web sites and perhaps thousands of https-speaking hosts so there
is the potential for this to expand the horizon a lot, despite the
admonition in the referenced text. Especially when one considers
the risible state of so-called "consent" on the web.

So if such analysis is part of the planned work, then I'd be
happy to support progressing it. If not... not.

Cheers,
S.

On 16/06/17 21:34, Paul Hoffman wrote:
> Greetings. We would like to propose that the work on DNS over HTTPS that is  currently embodied in the individual draft https://tools.ietf.org/html/draft-hoffman-dns-over-https-01 be dispatched at IETF 99.
> 
> The work has been discussed for the last nine months on the IETF-sponsored mailing list at https://www.ietf.org/mailman/listinfo/dnsoverhttp and was at the core of a bar bof in Seoul attended by around 80 people with a general consensus that standardization would benefit this space. I understand the draft should be resubmitted with the dispatch naming convention and will be very soon.
> 
> This seems to us to be an Application protocol, but the httpbis WG generally does not take on how-to-use HTTP (that is, "foo over HTTP" work items), so dispatch's help in progressing the work would be appreciated. We emphasize that we seek work consistent with the goals of this previous work (and believe it to be a strong starting point), but the actual protocol specification is of course a matter of IETF consensus not pre-determined by that draft.
> 
> As a bit of background, the Internet of course does not always provide good end-to-end reachability for DNS transport and this is especially true when using confidential and integrity transports for DNS. On-path network devices may spoof DNS responses, block DNS requests, track DNS activity, or just redirect DNS queries to different DNS servers that give less-than-honest answers.
> 
> This work focuses on interacting with DNS servers, not just using encapsulation as a tunnel. Using secure HTTPS provides an alternative transport option and also provides a mechanism for obtaining and using DNS data in web browsers, both natively and in security contexts governed by the Same-Origin security policy.
> 
> Another clear goal of the approach is to be a good fit for the HTTP protocol: good answers for caching, support for an ecosystem of different media types (such as both traditional DNS framing and more web-friendly things like JSON), and leverage of the multiplexing and prioritization schemes modern HTTP can provide.
> 
> Use of HTTPS is very common, of course, and the ability to use an established connection to carry DNS information can provide both performance and confidentiality benefits over other approaches in circumstances when HTTPS is the prominent transport available. This proposal should not be considered exclusive or competitive with the valuable mechcanisms of the drive WG.
> 
> Paul and Patrick
> _______________________________________________
> dispatch mailing list
> dispatch@ietf.org
> https://www.ietf.org/mailman/listinfo/dispatch
>