Re: [dns-privacy] DNS and QUIC,HTTP/3 Long term vision...

["Chris Box (BT)" <[e-mail]>]

Vinny,

Christian makes a number of good points. I will just add that your original
question assumes that the client wishes to send most or all of its DNS
queries directly to the content provider it is talking to. The ADD working
group is founded on the concept of needing to discover recursive resolvers,
and very often these are not the same endpoints that the web content is
served from. This implies that reuse of an existing HTTP/3 connection that
was established for retrieving web content, will not be the end goal for
DNS queries. Sometimes it'll happen, yes, but certainly not all the time.
It is far more likely that DNS will continue to be an independent layer,
served by its own set of servers that has only *some* overlap with the set
that serves web content.

Chris



On Wed, 7 Oct 2020 at 17:25, Christian Huitema <[e-mail]> wrote:

> There is indeed some extra per request overhead for Doh over HTTP3 versus
> Dns over QUIC, but I don't think that is the deciding factor. I think that
> the two other decision factors are for the client the privacy risks linked
> to cookies and other forms of HTTP tracking, and for the server the
> additional attack surface caused by adding an HTTP server stack to the DNS
> service. These factors may play out differently in the stub to recursive
> scenario and in the recursive to authoritative scenario.
>
> In HTTP-3, each DNS request would be carried by as a POST command, which
> requires a Header Frame to carry the HTTP header parameters and a Data
> Frame that carries the actual data. Each reply also requires a Header Frame
> and a Data Frame. In the fairly minimal implementation of HTTP-3 in
> Picoquic, the HTTP header carries the name of the Request URL, the name of
> the Http Server, and the content type. The Data Frame header carries the
> content length. The typical overhead for a request would be 16 to 32 bytes,
> depending on the length of server name and URL; the overhead per response
> will be 21 bytes. A full implementation of HTTP-3 would use header
> compression to reduce the size of the query overhead, but might use an
> additional set of HTTP header elements, including cookies, so the Header
> Frames might be larger in both directions, with a range of header size from
> a few dozen to a few hundred bytes.
>
> Running over HTTP brings to the DNS the privacy issues of HTTP. Cookies
> and other headers are used to manage content and caches, but also identify
> the users and enable a variety of surveillance scenarios. If a DoH query is
> multiplexed inside a regular HTTP session, the query will be associated
> with all the user information gathered in the session, which creates an
> important privacy exposure. This is definitely a greater exposure than a
> regular DNS query, in which the main identifying information is an IP
> address.
>
> On the server side, running over HTTP implies running on top of an HTTP
> server engine. This brings in a lot of code, some of it complex. It might
> be well tested and well maintained code, typically much better tested and
> maintained than if a server operator attempted to develop a specialized
> implementation of HTTP, but this is still a very large additional attack
> surface. Moreover, the HTTP code only remains "well maintained" if the
> operators regularly apply updates, which adds an operational constraint.
>
> I think that the exposure and overhead issues imply that solutions like
> DoT or DoQ should be preferred to DoH in recursive to authoritative
> scenarios. They should also be preferred when the stub resolver is part of
> the operating system, because operating system resolvers would normally not
> mix their queries with existing HTTP sessions, and thus don't get any
> advantage from "integrating to the web" -- unless of course firewall
> traversal is a big issue.
>
> -- Christian Huitema
>
>
> On 10/7/2020 8:31 AM, Tommy Pauly wrote:
>
> DoH is designed to be multiplexed with other HTTP requests. This is
> already possible with HTTP/2, and HTTP/3 carries on that ability. In order
> to take advantage of multiplexing, even with QUIC, you need some
> application-layer awareness of the content of the streams, which is why
> this is more practical with DoH than DoQ.
>
> I’m not sure how prevalent the multiplexing is today. For example, in our
> system implementation on iOS/macOS, DoH connections are made by the system
> DNS daemon and thus are not easy to multiplex with requests. However,
> that’s just one model, and there are certainly cases where the application
> would know it could multiplex a priori (and thus do DoH in the
> application), or could recognize that DNS results point to the same address
> as the DoH server, and start multiplexing after the fact.
>
> Thanks,
> Tommy
>
> On Oct 7, 2020, at 7:39 AM, Vinny Parla (vparla) <
> vparla=[e-mail]> wrote:
>
> Hi,
>
> What I am driving at in my original question is do we envision mixing
> Content and DNS together in a multiplexed session or will DNS continue to
> be an entirely independent channel (whether over HTTP/2 /3 Do53 DoQ DoH).
>
> -Vinny
>
> *From:* Tommy Pauly <tpauly=[e-mail]>
> *Sent:* Wednesday, October 7, 2020 9:23 AM
> *To:* James <[e-mail]>
> *Cc:* Vinny Parla (vparla) <[e-mail]>; [e-mail]
> *Subject:* Re: [dns-privacy] DNS and QUIC,HTTP/3 Long term vision...
>
> Can you cite this claim about DNS over HTTP/3? The per-query cost once an
> HTTP/3 connection is established should be minimal. If you’re taking into
> account all setup overhead for an HTTPS connection as a “per query” cost,
> that’s not representative of how DoH is reasonably used (and would be a
> issue with existing DoH).
>
> Thanks,
> Tommy
>
>
> On Oct 6, 2020, at 2:03 PM, James <[e-mail]> wrote:
>
> My most recent observations of discussions around DNS over QUIC and HTTP/3
> was that some folks had attempted DNS over HTTP/3, however the overheads
> (~14KiB for a query at worst-case) made it impractical and infeasible. With
> regards to DNS over QUIC, the current dprive working group adopted draft
> [1] is focusing on stub to recursive, but not necessarily as a multiplex
> with an existing QUIC connection.
>
> - J
>
> 1: https://tools.ietf.org/html/draft-ietf-dprive-dnsoquic-00
>
> On Mon, 5 Oct 2020 at 17:31, Vinny Parla (vparla) <vparla=
> [e-mail]> wrote:
>
> Hi,
>
> It was suggested that I ask this question on the 3 lists:
>
> Now that QUIC & HTTP/3 is imminent…
>
> I would like to know what the opinion is of the community on the long term
> view of DNS.
> Would DNS remain an independent channel or would it be subsumed in a
> multiplexed stream via HTTP/3 in some future version?
>
> For example, would a browser perform DNS queries over a QUIC multiplexed
> session?
>  (e.g. similar to how today an http proxy can perform DNS queries on
> behalf of the client using that proxy)
>
> Would love to hear from implementors what their long term view is of this
> in particular.
>
> Thanks,
>
> -Vinny
>
> _______________________________________________
> dns-privacy mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dns-privacy
>
> _______________________________________________
> dns-privacy mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dns-privacy
>
>
>
> _______________________________________________
> dns-privacy mailing [e-mail]://www.ietf.org/mailman/listinfo/dns-privacy
>
> _______________________________________________
> dns-privacy mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dns-privacy
>