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

[Christian Huitema <[e-mail]>]

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):
>
>    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.

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