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

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 <paul.hoffman@icann.org>
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
>