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

Richard Barnes <> Fri, 16 June 2017 22:37 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 01B371287A5 for <>; Fri, 16 Jun 2017 15:37:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 3Ab58XLNGeKP for <>; Fri, 16 Jun 2017 15:37:18 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:400c:c09::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 4BE09127B31 for <>; Fri, 16 Jun 2017 15:37:18 -0700 (PDT)
Received: by with SMTP id u195so21745696wmd.1 for <>; Fri, 16 Jun 2017 15:37:18 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=Mu1aJbZuW2Ahbm1EFz09/JNeNjO8uLpdUZhqaOzwKiw=; b=I2Fm2fYk8bFRqhGWwclYvcx6uEryglQQh6Ts7AhGNUCsLsUnLERjOxNTS/TAGnef8H NTFVBgEFdwqctkpUw4kaJvoPHDFdgnrJobpNvLQ9a3rPhwEk2wcvCa0hjQVBAJlwxHzL Q8Lc6m0D12MjbHhuXnrezg5vyYTDTpS3+xiQJBDMRu8o07P2pgC7sg2twEzsdq/1hznA g9KbHYYos3UE33ut0k3JKqUSII9YE4d0T2jjH9CvBKIFJ/U31oOmK7lpx6cEWtMQKr+J 1p0rqKzSQhsKucuPJRvmCHJQpw5m32EMu6rG9lvdMj/wgPBz5fa3n5MXdZUZEoXCrMKi KQmw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=Mu1aJbZuW2Ahbm1EFz09/JNeNjO8uLpdUZhqaOzwKiw=; b=HfiUSCEwkkXkbstQiE6H88ItKSpAE9TzrNI9r/EL/YsJZmVa8/3WigFZwHIwPUgf6I 80HZOqFdvmSmkfk3kilvJbuR3ppeIQ2JYeFhV2v58VzAdiIWS0oKZHYXXKSf80lgnYaY BAxZ0vADtt2aOCdrf6rNLKsyg+uYXWfvudYRAC84RVoPPS9y6JVpgdHqVugXSnk8N8TO 0pR0q51YDnEJJkOWhlg7h7VmVSzHRuum5lJJ2YGHSQHcr7Cg3gxL1o1WmkMN9BDqzgL1 zV2FZTJI0uDsyGPK6NAQzKghf2OU9Si3dorQOLbSaoRIFuS/Rk4/z1FxMO4WnA5LaUZ4 p4VQ==
X-Gm-Message-State: AKS2vOzZqxGf/TvPVrdjP6N0LjHhm+8OYeYGNl8MEELQPm3k1a9o/m/C HT6/VBTeTVu4+i6OWhEG/W8yVmpA1jUk
X-Received: by with SMTP id u12mr8796342wmd.15.1497652636603; Fri, 16 Jun 2017 15:37:16 -0700 (PDT)
MIME-Version: 1.0
Received: by with HTTP; Fri, 16 Jun 2017 15:37:15 -0700 (PDT)
In-Reply-To: <>
References: <>
From: Richard Barnes <>
Date: Fri, 16 Jun 2017 18:37:15 -0400
Message-ID: <>
To: Paul Hoffman <>
Cc: "" <>
Content-Type: multipart/alternative; boundary="001a114434a066ea0505521b6ddd"
Archived-At: <>
Subject: Re: [dispatch] New proposed work: DNS over HTTPS
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: DISPATCH Working Group Mail List <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 16 Jun 2017 22:37:21 -0000

Assuming we keep this bounded to the question of how to map DNS
request/response pairs to HTTP request/response pairs, with a little bit of
JSON syntax to make programming nice, this seems like a nicely bounded
piece of work that would be well-suited to a small working group.

Looking back at that the Bar BoF, however, I would be *very* wary of scope
creep, so the charter should be written very tightly and enforced by the
chairs and ADs.

On Fri, Jun 16, 2017 at 4:34 PM, Paul Hoffman <>

> Greetings. We would like to propose that the work on DNS over HTTPS that
> is  currently embodied in the individual draft
> be dispatched
> at IETF 99.
> The work has been discussed for the last nine months on the IETF-sponsored
> mailing list at 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