Re: [Doh] some privacy ponderings wrt HTTPs and plain DNS

[Howard Chu <[e-mail]>]

I was asked to poke my head into this conversation. Fwiw I think Sara 
Dickinson has already raised several valid concerns, but I haven't seen them 
all being addressed.

Sara Dickinson <[e-mail]> Mon, 18 June 2018 13:47 UTC
> 
> 
>> On 18 Jun 2018, at 13:49, nusenu <[e-mail]>; wrote:
>> 
>> Signed PGP part
>>> As noted, I don't know if this has a place in the draft, but I'd recommend
>>> DoH clients to:
>>> 
>>> * Set their Agent to 'DoH client', no matter what browser/library
>>> * Do not pass non-essential HTTP headers (like language)
>>> * Do not allow the DoH server to set cookies
>>> * Ponder TLS sessions resumption data settings
>>> * Think about all other ways in which HTTP can be tracked (HSTS?)
>>> 
>>> Thoughts?

My preference would be that only bare-minimum HTTP requests are ever 
generated. The whole point of this is to enhance user privacy, you can't just 
immediately toss user privacy out the door at step 1.

   GET foo HTTP/1.1
   Host: foo.bar.com

I might even go further and drop the "Host:" header:

   GET foo HTTP/1.0

If this is really going to replace plain DNS over UDP, everything else is not 
only breaking privacy but also useless overhead.

>> Thanks for this, I find it rather important to avoid introducing new data 
>> collection opportunities (at the resolver) that haven't been there on plain DNS 
>> and support your recommendations to minimize data exposure.
>> 
>> Ideally all DoH clients look the same from the DoH server perspective.
>> This this will never be completely the case but we should try to minimize
>> the DoH client fingerprintability.
>> 
>> I hope the minimization of the DoH client fingerprint becomes a mandatory part
>> in the document.
> 
> +1 on this. DNSOP and DPRIVE have both acknowledged that client identifiers in DNS messages directly compromise user privacy and have attempted to minimise or mitigate their use (for example see RFC7626, RFC7871 or draft-tale-dnsop-edns0-clientid). The DoH WG should be doing the same (or at least no less).
> 
>> 
>> This is also in-line with the spirit of RFC6973
>> Privacy Considerations for Internet Protocols
>> 
>> specifically section 6.1 and 7.1
>> https://tools.ietf.org/html/rfc6973#section-6.1
>> https://tools.ietf.org/html/rfc6973#section-7.1
>> 
>> "What identifiers could be omitted or be made less
>> identifying while still fulfilling the protocol's goals?"
>> is always a good question to ask.
> 
> And given that the charter says 
> “The working group will analyze the security and privacy issues that
> could arise from accessing DNS over HTTPS. “
> 
> it suddenly strikes me that this draft doesn’t contain a Privacy Considerations section. I would suggest that one is added to address this issue and offer to help with text on that.

Absolutely. These sections are mandatory now, it's surprising the draft has 
gotten this far without one.

> On a technical note do we have 2 use cases to deal with?
> - one where dedicated connections are used for DoH (i.e. where only DoH requests are made)
> - one where DoH requests are intermingled on the same connection with existing traffic (which will most likely include headers already identifying the client)

This sounds quite implementation-specific and not really within scope of this 
spec.

-- 
   -- Howard Chu
   CTO, Symas Corp.           http://www.symas.com
   Director, Highland Sun     http://highlandsun.com/hyc/
   Chief Architect, OpenLDAP  http://www.openldap.org/project/