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

From: "Vinny Parla (vparla)" <[email-masked]>
Date: Mon, 5 Oct 2020 15:31:42 +0000

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

---

From: James <[email-masked]>
Date: Tue, 6 Oct 2020 23:03:24 +0200

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=
[email-masked]> wrote:

> Now that QUIC & HTTP/3 is imminent…
>
>
>
>  (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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dns-privacy
>

---

From: Tommy Pauly <[email-masked]>
Date: Wed, 07 Oct 2020 06:22:37 -0700

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 <[email-masked]> 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 <https://tools.ietf.org/html/draft-ietf-dprive-dnsoquic-00>
> On Mon, 5 Oct 2020 at 17:31, Vinny Parla (vparla) <vparla=[email-masked] <mailto:[email-masked]>> wrote:
> Hi,
> 
>  
> 
> 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
> 
>  
> 
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/dns-privacy <https://www.ietf.org/mailman/listinfo/dns-privacy>
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/dns-privacy <https://www.ietf.org/mailman/listinfo/dns-privacy>

---

From: "Vinny Parla (vparla)" <[email-masked]>
Date: Wed, 7 Oct 2020 14:39:59 +0000

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=[email-masked]> 
Sent: Wednesday, October 7, 2020 9:23 AM
To: James <[email-masked]>
Cc: Vinny Parla (vparla) <[email-masked]>; [email-masked]
Subject: Re: [dns-privacy] DNS and QUIC,HTTP/3 Long term vision...

Thanks,

Tommy

On Oct 6, 2020, at 2:03 PM, James <[email-masked] <mailto:[email-masked]> > wrote:

- J

On Mon, 5 Oct 2020 at 17:31, Vinny Parla (vparla) <vparla=[email-masked] <mailto:[email-masked]> > wrote:

Hi,

Thanks,

-Vinny

_______________________________________________
dns-privacy mailing list
 <mailto:[email-masked]> [email-masked]
 <https://www.ietf.org/mailman/listinfo/dns-privacy> https://www.ietf.org/mailman/listinfo/dns-privacy

---

From: James <[email-masked]>
Date: Wed, 7 Oct 2020 17:09:16 +0200

Tommy:

I suspect they are likely on list and can speak for themselves and do a 
much better job of it, however aiui it was the absolute worst case where 
QUIC connection setup was also included. This was a brief hallway 
discussion back in Singapore so things may have progressed.

Vinny:

The draft I cited makes its specific use case not to include 
multiplexing as it announces a separate ALPN and operates on a 
different, dedicated port. If my memory serves me right previous 
discussion in both the doh WG and related DNS working groups on the 
subject of multiplexing were largely dismissive of it over a lack of 
separation of concerns, privacy, among others.

- J

On 07/10/2020 14:39, Vinny Parla (vparla) 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=[email-masked]>
> *Sent:* Wednesday, October 7, 2020 9:23 AM
> *To:* James <[email-masked]>
> *Cc:* Vinny Parla (vparla) <[email-masked]>; [email-masked]
> *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 <[email-masked]
>     <mailto:[email-masked]>> 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
>     <https://tools.ietf.org/html/draft-ietf-dprive-dnsoquic-00>
>
>     On Mon, 5 Oct 2020 at 17:31, Vinny Parla (vparla)
>     <vparla=[email-masked]
>     <mailto:[email-masked]>> wrote:
>
>         Hi,
>
>         Would DNS remain an independent channel or would it be
>         subsumed in a multiplexed stream via HTTP/3 in some future
>         version?
>
>          (e.g. similar to how today an http proxy can perform DNS
>         queries on behalf of the client using that proxy)
>
>         <https://www.ietf.org/mailman/listinfo/dns-privacy>
>
>     <https://www.ietf.org/mailman/listinfo/dns-privacy>
>

---

From: Tommy Pauly <[email-masked]>
Date: Wed, 07 Oct 2020 08:31:27 -0700

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=[email-masked]> wrote:
> 
> Hi,
>  
> On Oct 6, 2020, at 2:03 PM, James <[email-masked] <mailto:[email-masked]>> wrote:
>

---

From: "Vinny Parla (vparla)" <[email-masked]>
Date: Wed, 7 Oct 2020 16:13:07 +0000

Hi Tommy,

Thanks for the response.

Would you envision the iOS / macOS implementation following the current model - long term - of keeping DNS as an OS resolver function and hence independent?

I concur that applications like Browsers can multiplex this today with Content.  

So the question for those implementors is would they do so in practice or continue to keep DNS as an independent channel altogether.

-Vinny

From: Tommy Pauly <tpauly=[email-masked]> 
Sent: Wednesday, October 7, 2020 11:31 AM
To: Vinny Parla (vparla) <[email-masked]>
Cc: James <[email-masked]>; [email-masked]
Subject: Re: [dns-privacy] DNS and QUIC,HTTP/3 Long term vision...

Thanks,

Tommy

On Oct 7, 2020, at 7:39 AM, Vinny Parla (vparla) <vparla=[email-masked] <mailto:vparla=[email-masked]> > wrote:

Hi,

-Vinny

From: Tommy Pauly <tpauly=[email-masked] <mailto:tpauly=[email-masked]> > 
Sent: Wednesday, October 7, 2020 9:23 AM
To: James <[email-masked] <mailto:[email-masked]> >
Cc: Vinny Parla (vparla) <[email-masked] <mailto:[email-masked]> >; [email-masked] <mailto:[email-masked]> 
Subject: Re: [dns-privacy] DNS and QUIC,HTTP/3 Long term vision...

Thanks,

Tommy

- J

1:  <https://tools.ietf.org/html/draft-ietf-dprive-dnsoquic-00> https://tools.ietf.org/html/draft-ietf-dprive-dnsoquic-00

On Mon, 5 Oct 2020 at 17:31, Vinny Parla (vparla) <vparla= <mailto:[email-masked]> [email-masked]> wrote:

Hi,

Thanks,

-Vinny

---

From: Christian Huitema <[email-masked]>
Date: Wed, 7 Oct 2020 09:21:25 -0700

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)
>> <mailto:vparla=[email-masked]>> wrote:
>>
>> Hi,
>>  
>> 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=[email-masked]
>> <mailto:tpauly=[email-masked]>> 
>> *To:* James <[email-masked] <mailto:[email-masked]>>
>> *Cc:* Vinny Parla (vparla) <[email-masked]
>> <mailto:[email-masked]>>; [email-masked]
>> <mailto:[email-masked]>
>> 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
>>     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
>>

---

From: "Chris Box (BT)" <[email-masked]>
Date: Wed, 7 Oct 2020 18:04:46 +0100

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 <[email-masked]> 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.
>
> 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.
>
> 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.
>
> 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.
>
> 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
>
>
> 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=[email-masked]> wrote:
>
> Hi,
>
> 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
>
> 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
>
>
> dns-privacy mailing [email-masked]://www.ietf.org/mailman/listinfo/dns-privacy
>

---

From: "Vinny Parla (vparla)" <[email-masked]>
Date: Wed, 7 Oct 2020 18:00:47 +0000

Hi,

Some excellent and detailed responses to my questions from both you and Christian.  Thank you.

A CDN could aggregate both Content and DNS in a single channel as nothing in the protocol(s) prevents this, correct?

While discovery might preclude this behavior from happening, ultimately it is all about implementation. 

Hence why I am trying to see what the implementors (particularly Browsers) might envision here.  

Hopefully as you state they are kept independent.

As a Recursive DNS Security Provider, what worries me is the Sometimes aspect of this that you call out below.   

Sometimes means evasion at the end of the day so I would love to get a feel for how prevalent that might be.

-Vinny

From: Chris Box (BT) <[email-masked]> 
Sent: Wednesday, October 7, 2020 1:05 PM
To: Vinny Parla (vparla) <[email-masked]>
Cc: [email-masked]
Subject: Re: [dns-privacy] DNS and QUIC,HTTP/3 Long term vision...

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 <[email-masked] <mailto:[email-masked]> > 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

Thanks,

Tommy

Hi,

-Vinny

Thanks,

Tommy

- J

Hi,

Thanks,

-Vinny

---

From: Andrew Campling <[email-masked]>
Date: Thu, 8 Oct 2020 08:32:40 +0000

Important though browsers are for some, DNS is an Internet protocol and needs to work for a wide range of devices and clients.  Mandating its absorption into a multiplexed stream via HTTP/3 seems unnecessary, irrespective of the potential performance gains and other possible benefits for web clients.

Andrew

From: Vinny Parla (vparla) <[email-masked]>
Sent: 07 October 2020 15:40
To: Tommy Pauly <tpauly=[email-masked]>; James <[email-masked]>
Cc: [email-masked]
Subject: Re: [dns-privacy] DNS and QUIC,HTTP/3 Long term vision...

Hi,

-Vinny

From: Tommy Pauly <tpauly=[email-masked]<mailto:tpauly=[email-masked]>>
Sent: Wednesday, October 7, 2020 9:23 AM
To: James <[email-masked]<mailto:[email-masked]>>
Cc: Vinny Parla (vparla) <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Subject: Re: [dns-privacy] DNS and QUIC,HTTP/3 Long term vision...

Thanks,
Tommy

On Oct 6, 2020, at 2:03 PM, James <[email-masked]<mailto:[email-masked]>> wrote:

- J

On Mon, 5 Oct 2020 at 17:31, Vinny Parla (vparla) <vparla=[email-masked]<mailto:[email-masked]>> wrote:
Hi,

Thanks,

-Vinny

_______________________________________________
dns-privacy mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/dns-privacy
_______________________________________________
dns-privacy mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/dns-privacy

---

From: "Vinny Parla (vparla)" <[email-masked]>
Date: Thu, 8 Oct 2020 15:12:26 +0000

Hi Andrew,

I agree with your view and am not in favor of aggregating Content and DNS together, although I can see arguments for doing this.

I am just wondering if Browser implementors have plans to do this in the future as I need to deal with both OS DNS and Browser (app) DNS scenarios.

>From Tommy’s response I am hopeful the OS implementors won’t do this in the future and will keep DNS an independent mechanism.

-Vinny

From: Andrew Campling <[email-masked]> 
Sent: Thursday, October 8, 2020 4:33 AM
To: Vinny Parla (vparla) <[email-masked]>; Tommy Pauly <tpauly=[email-masked]>; James <[email-masked]>
Cc: [email-masked]
Subject: RE: [dns-privacy] DNS and QUIC,HTTP/3 Long term vision...

Andrew 

From: Vinny Parla (vparla) <[email-masked] <mailto:[email-masked]> > 
Sent: 07 October 2020 15:40
To: Tommy Pauly <tpauly=[email-masked] <mailto:tpauly=[email-masked]> >; James <[email-masked] <mailto:[email-masked]> >
Cc: [email-masked] <mailto:[email-masked]> 
Subject: Re: [dns-privacy] DNS and QUIC,HTTP/3 Long term vision...

Hi,

-Vinny

Thanks,

Tommy

- J

Hi,

Thanks,

-Vinny

---

From: Eric Orth <[email-masked]>
Date: Thu, 8 Oct 2020 11:59:35 -0400

For Chrome, we're currently taking some steps to ensure connection
separation between DoH requests and normal content requests.  More
specifically, we currently disallow DoH requests from sharing a connection
with any requests that are not also blocked from sending or receiving
cookies (as are the DoH requests), and we're considering further completely
blocking DoH requests from sharing connections with non-DoH.  Primary
motivation is privacy.  If DNS is multiplexed up with cookie-containing (or
otherwise user-identifying) requests, makes it too easy for even an
attempting-to-be-anonymous DNS service to accidentally log requests
correlated up with user identity.

Plans may change in the future as we discover more usecases and if these
scenarios become more relevant with some of the ADD proposals around
domains designating preferred resolvers, but at least for now, I would
anticipate Chrome DNS requests always staying at least somewhat separated
from Chrome content requests.

On Thu, Oct 8, 2020 at 11:13 AM Vinny Parla (vparla) <vparla=
[email-masked]> wrote:

> Hi Andrew,
>
>
>
> I agree with your view and am not in favor of aggregating Content and DNS
> together, although I can see arguments for doing this.
>
> I am just wondering if Browser implementors have plans to do this in the
> future as I need to deal with both OS DNS and Browser (app) DNS scenarios.
>
>
>
> From Tommy’s response I am hopeful the OS implementors won’t do this in
> the future and will keep DNS an independent mechanism.
>
>
>
> -Vinny
>
>
>
> *From:* Andrew Campling <[email-masked]>
> *Sent:* Thursday, October 8, 2020 4:33 AM
> *To:* Vinny Parla (vparla) <[email-masked]>; Tommy Pauly <tpauly=
> [email-masked]>; James <[email-masked]>
> *Cc:* [email-masked]
> *Subject:* RE: [dns-privacy] DNS and QUIC,HTTP/3 Long term vision...
>
>
>
> Important though browsers are for some, DNS is an Internet protocol and
> needs to work for a wide range of devices and clients.  Mandating its
> absorption into a multiplexed stream via HTTP/3 seems unnecessary,
> irrespective of the potential performance gains and other possible benefits
> for web clients.
>
>
>
> Andrew
>
>
>
> *From:* Vinny Parla (vparla) <[email-masked]>
> *Sent:* 07 October 2020 15:40
> *To:* Tommy Pauly <tpauly=[email-masked]>; James <
> [email-masked]>
> *Cc:* [email-masked]

---

From: Andrew Campling <[email-masked]>
Date: Fri, 9 Oct 2020 08:04:46 +0000

This seems like a great example of best practice.  I wonder though whether it highlights a weakness in the protocol design if it is necessary to rely on goodwill by developers in order to protect the privacy of end users?  Perhaps future developments would take a different path, guided by the policy recently set out by the IAB in RFC8890.

Andrew

From: Eric Orth <[email-masked]>
Sent: 08 October 2020 17:00
To: Vinny Parla (vparla) <vparla=[email-masked]>
Cc: Andrew Campling <[email-masked]>; Tommy Pauly <tpauly=[email-masked]>; James <[email-masked]>; [email-masked]
Subject: Re: [dns-privacy] DNS and QUIC,HTTP/3 Long term vision...

For Chrome, we're currently taking some steps to ensure connection separation between DoH requests and normal content requests.  More specifically, we currently disallow DoH requests from sharing a connection with any requests that are not also blocked from sending or receiving cookies (as are the DoH requests), and we're considering further completely blocking DoH requests from sharing connections with non-DoH.  Primary motivation is privacy.  If DNS is multiplexed up with cookie-containing (or otherwise user-identifying) requests, makes it too easy for even an attempting-to-be-anonymous DNS service to accidentally log requests correlated up with user identity.

Plans may change in the future as we discover more usecases and if these scenarios become more relevant with some of the ADD proposals around domains designating preferred resolvers, but at least for now, I would anticipate Chrome DNS requests always staying at least somewhat separated from Chrome content requests.

On Thu, Oct 8, 2020 at 11:13 AM Vinny Parla (vparla) <vparla=[email-masked]<mailto:[email-masked]>> wrote:
Hi Andrew,

-Vinny

From: Andrew Campling <[email-masked]<mailto:[email-masked]>>
Sent: Thursday, October 8, 2020 4:33 AM
To: Vinny Parla (vparla) <[email-masked]<mailto:[email-masked]>>; Tommy Pauly <tpauly=[email-masked]<mailto:[email-masked]>>; James <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>
Subject: RE: [dns-privacy] DNS and QUIC,HTTP/3 Long term vision...

Andrew

From: Vinny Parla (vparla) <[email-masked]<mailto:[email-masked]>>
Sent: 07 October 2020 15:40
To: Tommy Pauly <tpauly=[email-masked]<mailto:tpauly=[email-masked]>>; James <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [dns-privacy] DNS and QUIC,HTTP/3 Long term vision...

Hi,

-Vinny

Thanks,
Tommy

- J

Thanks,

-Vinny

---

From: Tommy Pauly <[email-masked]>
Date: Fri, 09 Oct 2020 15:32:42 -0700

Hi Andrew,

At least the cookie aspect of this isn’t just a “best practice” of one implementer, but something indeed built into the protocol spec (https://tools.ietf.org/html/rfc8484 <https://tools.ietf.org/html/rfc8484>):

   Determining whether or not a DoH implementation requires HTTP cookie
   [RFC6265 <https://tools.ietf.org/html/rfc6265>] support is particularly important because HTTP cookies are
   the primary state tracking mechanism in HTTP.  HTTP cookies SHOULD
   NOT be accepted by DOH clients unless they are explicitly required by
   a use case.

I think it is incorrect to characterize that DoH has a flawed design by basing itself on a protocol that allows cookies, or allows multiplexing. These are certainly tools provided by HTTP, but it is up to use them or not as appropriate. “Bad” implementations can put information in just about any protocol that could be used for tracking users.

DoH has many benefits to the user for privacy and performance, and I consider it to be entirely in the spirit of RFC 8890.

Thanks,
Tommy

> On Oct 9, 2020, at 1:04 AM, Andrew Campling <[email-masked]> wrote:
> 
> On Thu, Oct 8, 2020 at 11:13 AM Vinny Parla (vparla) <vparla=[email-masked] <mailto:[email-masked]>> wrote:
> Hi Andrew,
>  
> From: Andrew Campling <[email-masked] <mailto:[email-masked]>> 
> To: Vinny Parla (vparla) <[email-masked] <mailto:[email-masked]>>; Tommy Pauly <tpauly=[email-masked] <mailto:[email-masked]>>; James <[email-masked] <mailto:[email-masked]>>
> From: Vinny Parla (vparla) <[email-masked] <mailto:[email-masked]>> 
> To: Tommy Pauly <tpauly=[email-masked] <mailto:tpauly=[email-masked]>>; James <[email-masked] <mailto:[email-masked]>>
> From: Tommy Pauly <tpauly=[email-masked] <mailto:tpauly=[email-masked]>> 
> To: James <[email-masked] <mailto:[email-masked]>>
> Cc: Vinny Parla (vparla) <[email-masked] <mailto:[email-masked]>>; [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/dns-privacy <https://www.ietf.org/mailman/listinfo/dns-privacy>_______________________________________________
> dns-privacy mailing list

---

From: Christian Huitema <[email-masked]>
Date: Fri, 9 Oct 2020 18:28:16 -0700

On 10/9/2020 3:32 PM, Tommy Pauly wrote:

> Hi Andrew,
>
> At least the cookie aspect of this isn’t just a “best practice” of one
> implementer, but something indeed built into the protocol spec
> (https://tools.ietf.org/html/rfc8484):
>
> I think it is incorrect to characterize that DoH has a flawed design
> by basing itself on a protocol that allows cookies, or allows
> multiplexing. These are certainly tools provided by HTTP, but it is up
> to use them or not as appropriate. “Bad” implementations can put
> information in just about any protocol that could be used for tracking
> users.

I am not sure about that. These days, if a protocol design allow it to
be used for surveillance, you can be pretty sure that it will be.

Maybe DoH should add a requirement for servers to reject requests on
multiplexed connections, or reject requests that come with cookies
attached. That would provide a strong incentive for clients to do the
right thing.

>
> DoH has many benefits to the user for privacy and performance, and I
> consider it to be entirely in the spirit of RFC 8890.

OTOH, if an implementation (like Chrome) is going to use a dedicated
connection for DoH (H2 or H3), then it probably could just as well use
DoT or DoQ. The only issue is firewalls that would filter based on the
DoT or DoQ ALPN, but ECH/ESNI would easily fix that. Hard to believe
that this would not get better performance.

-- Christian Huitema

---

From: Andrew Campling <[email-masked]>
Date: Sun, 11 Oct 2020 20:22:37 +0000

On 10/10/2020 2:28 AM, Christian Huitema wrote:

At least the cookie aspect of this isn’t just a “best practice” of one implementer, but something indeed built into the protocol spec (https://tools.ietf.org/html/rfc8484):

   [RFC6265<https://tools.ietf.org/html/rfc6265>] support is particularly important because HTTP cookies are

   a use case.

I am not sure about that. These days, if a protocol design allow it to be used for surveillance, you can be pretty sure that it will be.

That’s my concern too.  If the capability exists then it will be used, the opportunity for monetisation (and other negative outcomes) is too great.

Maybe DoH should add a requirement for servers to reject requests on multiplexed connections, or reject requests that come with cookies attached. That would provide a strong incentive for clients to do the right thing.

My European DNS Resolver Policy for resolver operators includes the following: “[operators of DNS resolver services] SHOULD NOT use or require HTTP cookies when communicating with DNS clients that use HTTP-based DNS transports for resolution”.

Andrew

---

From: "Vinny Parla (vparla)" <[email-masked]>
Date: Sun, 11 Oct 2020 23:34:08 +0000

Hi,

I think that aggregation with Content is generally undesirable in terms of DoH.

However there are use cases for authentication of a DoH channel for enterprise scenarios that we should not simply dismiss as a ‘user tracking’ mechanism.

For example if an enterprise wants to build a Zero Trust solution and protect their private domain names to only those users authorized to access them.

In such a case, the enterprise would want an authenticated DoH channel to do that.

That authentication could be via mTLS on the DoH tls channel, OAuth or even WebAuthN.  

The point being there is a valid use case for doing this in a client implementation.

-Vinny

From: Andrew Campling <[email-masked]> 
Sent: Sunday, October 11, 2020 4:23 PM
To: Christian Huitema <[email-masked]>; Tommy Pauly <[email-masked]>
Cc: Eric Orth <[email-masked]>; [email-masked]; James <[email-masked]>; Vinny Parla (vparla) <[email-masked]>
Subject: RE: [dns-privacy] DNS and QUIC,HTTP/3 Long term vision...

Hi Andrew, 

   Determining whether or not a DoH implementation requires HTTP cookie
   [RFC6265 <https://tools.ietf.org/html/rfc6265> ] support is particularly important because HTTP cookies are
   the primary state tracking mechanism in HTTP.  HTTP cookies SHOULD
   NOT be accepted by DOH clients unless they are explicitly required by
   a use case.

Andrew