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

From: Paul Hoffman <[email-masked]>
Date: Fri, 16 Jun 2017 20:34:50 +0000

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

---

From: Richard Barnes <[email-masked]>
Date: Fri, 16 Jun 2017 18:37:15 -0400

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 <[email-masked]>
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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dispatch
>

---

From: Stephen Farrell <[email-masked]>
Date: Sat, 17 Jun 2017 13:33:30 +0100

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.

---

From: Paul Hoffman <[email-masked]>
Date: Sat, 17 Jun 2017 17:43:43 +0000

> happy to support progressing it. If not... not.

It wasn't part of the planned work because we thought we dealt with the issue you reported. It is now part of the planned work because it appears we undershot. This kind of consideration should definitely be discussed in the document.

--Paul

---

From: Stephen Farrell <[email-masked]>
Date: Sat, 17 Jun 2017 19:22:45 +0100

On 17/06/17 18:43, Paul Hoffman wrote:
>> So if such analysis is part of the planned work, then I'd be happy
>> to support progressing it. If not... not.
> 
> It wasn't part of the planned work because we thought we dealt with
> the issue you reported. It is now part of the planned work because it
> appears we undershot. This kind of consideration should definitely be
> discussed in the document.

Ack. So long as the analysis is done and appropriately
documented, then I'd be fine. I'm not sure myself how
much text that'd result in for this document - I guess
that'll depend on the results found.

S.

---

From: Mark Nottingham <[email-masked]>
Date: Sun, 18 Jun 2017 12:10:24 +1000

+1 to everything Richard says.

> On 17 Jun 2017, at 8:37 am, Richard Barnes <[email-masked]> wrote:
> 
> 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 <[email-masked]> wrote:

--
Mark Nottingham   https://www.mnot.net/

---

From: Martin Thomson <[email-masked]>
Date: Mon, 19 Jun 2017 10:25:36 +1000

> It wasn't part of the planned work because we thought we dealt with the issue you reported. It is now part of the planned work because it appears we undershot. This kind of consideration should def…

I've had a number of discussions about this recently, and I'm really
glad you say this.  The interaction between this work and recent
extensions to HTTP change the dynamics considerably.  I believe that
there is an answer to be had, but navigating the competing pressures
of connection coalescing, ORIGIN frames, Alt-Svc, and secondary
certificates isn't something we should be too dismissive of.

At best, I think that this introduces some new ways of thinking about
who resolves requests that need some care.