Re: [Doh] New Privacy Considerations Section Proposal

["Hewitt, Rory" <[e-mail]>]

I like Patrick's proposed wording along the lines of "...should use the 
minimal set of data that can achieve the desired feature set.", but I also 
like Ted's more explicit suggestion.



Perhaps this combination?:



"DoH clients should use the minimal set of data (e.g. headers, cookies) that 
can achieve the desired feature set whilst minimizing potentially identifying 
information being passed."



Just my $0.02...



Thanks,



Rory



From: Adam Roach [mailto:[e-mail]]
Sent: Wednesday, June 20, 2018 4:55 PM
To: Patrick McManus <[e-mail]>; Ted Hardie <[e-mail]>
Cc: DoH WG <[e-mail]>
Subject: 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 <[e-mail] 
<mailto:[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.










_______________________________________________
Doh mailing list
[e-mail] <mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/doh 
<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_doh&d=DwMDaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=h4goE6gK_ZaRrvwi4Hglaq0NyaBCb3I3XALyazxKb6w&m=7boz0IZ1KBlcynrJRZvHUlL6gh1y4uzb-x87ZvAPKpg&s=avFqKXoSyMVxMlVyRiyAICtyhhiq6eXCDBvftWeYx14&e=>