Re: [Doh] New Privacy Considerations Section Proposal

[Patrick McManus <[e-mail]>]

On Wed, Jun 20, 2018 at 6:14 PM, Ted Hardie <[e-mail]> wrote:

> Repeating the comment I made at Github:
>
> Is there a reason not to make a recommendation for the case of a DOH-only
> service?  The current text says:
>
> Implementations of DoH clients and servers need to consider the benefit
> and privacy impact of all these features, and their deployment context,
> when deciding whether or not to enable them.
>
> Would you consider a recommendation like "For DOH clients which do not
> intermingle DOH requests with other HTTP suppression of these headers and
> other potentially identifying headers is an appropriate data minimization
> strategy."?
>
>
there are some practical problems there. Big picture you need to weigh the
reasons these things get used in your implementation decisions. Its not
like TLS didn't know they had built a tracker with session tickets, yet
dprive recommended its use anyhow :)

every http feature has a reason an implementation might want want it in
doh. cookies can do useful things for auth. new compression algorithms
(which create a fingerprint on introduction just as surely as UA does)
enable better performance. etc.. UA strings have kept the web runinng, for
good and bad, across many unanticipated bugs for many years.. I'm not
saying those arguments win the day but its not really DoH's place to change
the properties of HTTP. Alt-Service provides great load balancing and
protocol evolution, but its basically a cache with a tracking implication
too.

It is an important goal of this work to leverage the HTTP ecosystem -
stripping out all the HTTP parts and leaving a tunnel doesn't give it any
value.

The picture is also complicated by the end to end message semantics of http
headers and how they interact with the hop to hop transport semantics of
the client or server. i.e. the notion of intermingle is not e2e, but
headers are. That's not really a driver, but something to keep in mind when
considering the limitations of text.

I'm more inclined in general to use words along the lines of "should use
the minimal set of data that can achieve the desired feature set." if
that's helpful, but I'm not eager to start working through individual
design decisions.