Re: [Doh] New Privacy Considerations Section Proposal

[as an individual]

I agree with Patrick's analysis here, and think the proposed text (plus 
the "minimal set of data" statement below) is likely to serve the 
purpose well. In particular, I agree with Patrick that the various 
features that have been cited so far each serve a useful purpose, and 
that such purposes may have a place in DoH deployments. Giving 
implementors a heads up about the privacy trade-offs seems appropriate. 
Mandating (MUST or SHOULD) that DoH runs over a minimal profile of HTTP 
seems to remove several of the advantages of using HTTP at all.

/a

On 6/20/18 6:03 PM, Patrick McManus wrote:
>
>
> On Wed, Jun 20, 2018 at 6:14 PM, Ted Hardie <ted.ietf@gmail.com 
> <mailto:ted.ietf@gmail.com>> 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.
>
>
>
>
> _______________________________________________
> Doh mailing list
> Doh@ietf.org
> https://www.ietf.org/mailman/listinfo/doh