[Doh] Is privacy a DoH protocol goal? (was: some privacy ponderings wrt HTTPs and plain DNS)

[nusenu <[e-mail]>]

(split from the original thread to clarify some general questions before
talking about how specific issues could be addressed)

> If you think User-Agent can be a problem, then you shouldn't use TLS
>  either.

Privacy is about risk reduction there is no 100% safe solution.

User-Agent strings are likely to be logged since many/most webserver configurations log it by default.
Many operators might store that data even if they have no use for it or not even an intention to store it.

I see a value in minimizing fingerprintability (and data collection) even if it doesn't make it impossible. 

It boils down to the following question:

Is privacy a DoH protocol goal?

If privacy is a DoH protocol goal:
- Privacy against whom? 
 - Your random eavesdropper on the wire? 
 - Your eavesdropper + resolver?
 - if the resolver is in scope: sending a non-hardcoded user-agent is counter the protocol goal.
- What are reasonable privacy expectations a user might have when using DoH?

Note: It is not entirely clear to me if privacy is a DoH protocol goal since the word "privacy"
does not appear in the current draft (11). 
Sara pointed to the relevant part in the charter:
> The working group will analyze the security and privacy issues that
> could arise from accessing DNS over HTTPS.

I guess "analyze" doesn't include to mitigate privacy issues(?), but the 
document aims at giving a overview of what the privacy implications 
of doing DNS over HTTPS are? Is this a correct interpretation?

If DoH's adversary model does not include the resolver:

Lets make it clear that the resolver might be able to learn more and track DoH clients more
than a current non-DoH resolver is able to track non-DoH clients due to all the privacy implications
HTTP has and that people who's threat model includes the resolver might want to use other protocols that
don't use HTTP?


kind regards,
nusenu
-- 
https://twitter.com/nusenu_
https://mastodon.social/@nusenu




> Sorry I remembered the old text. (It was once a "MUST" in the past.)
> 
> But what are you expecting with a DoH protocol running over 
> HTTP/1.0?

Nothing, I was merely pointing out that HTTP/2 is not required
and clients do not require HTTP/2 for DoH as of the current draft (11).


> When you look at the Client Hello packet, you will find different 
> browsers have different things in it. Even different versions of a 
> same browser are not identical. As far as I know, Chinese government
>  use this technique to block certain TLS protocols, including Tor and
>  OpenVPN. This is far far far more "plaintext fingerprintable" than a
>  User-Agent.

I agree that TLS provides identifiers for fingerprintability, I disagree
with "you shouldn't use TLS" because of it or 'we shouldn't care about user-agent
strings since there are fingerprintability issues in TLS'

> Additionally, detecting a server or a client's software version is 
> actually very easy. I knew there is a certain bug that can't handle 
> ECS headers well in a certain version of miekg/dns Go library. I 
> constructed a packet containing this certain header and sent it to 
> CloudFlare. They crashed and returned nothing. Now I knew 
> CloudFlare's DNS implementation was written in Go. And they even were
> even using the old version! (I'm not sure about now.) The client side
> is the same, as far as I know, miekg/dns has some difficulty 
> processing some Rcode values.
> 
> To conclude: Hiding User-Agent does nothing to protect privacy. 

It is a well understood that user agent strings provide identifying bits
for fingerprinting:

https://panopticlick.eff.org/static/browser-uniqueness.pdf
https://panopticlick.eff.org/about
https://panopticlick.eff.org/

Our disagreement probably arises from non-matching threat models.
That is the reason I like to have threat model definitions before
discussing mitigations.