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

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

Of course it depends on what you mean by 'privacy' versus 'security' 
versus...well, whatever. Personally I think privacy (as _I_ define it) is a 
goal of the members of the DoH WG and this mailing list in general, but not 
necessarily of DoH itself.

That all being said, I'm not clear on whether this discussion belongs as part 
of drafting this spec. If we're not going to include REQUIREMENTS in the spec 
to limit e.g. which request headers can be sent to a DoH server (which we're 
not even considering, I hope!), then it seems to me that all this discussion 
boils down to whether we should include a non-normative section in the spec 
about "best practices". If that's the case, then two things are clear to me:

	a) the wording of such a section is relatively unimportant and should be as 
generic as possible, probably based off Bert Hubert's original bullet points
	b) it's probably simpler/better to provide references to one or more existing 
documents which discuss general privacy practices (if they exist)

At any rate, I'd hate to see this discussion hold up a final draft.

Thanks,

Rory

-----Original Message-----
From: nusenu [mailto:[e-mail]]
Sent: Tuesday, June 19, 2018 5:31 AM
To: [e-mail]
Subject: [Doh] Is privacy a DoH protocol goal? (was: some privacy ponderings 
wrt HTTPs and plain DNS)

(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.