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

[Star Brilliant <[e-mail]>]

Hi,

I don't think we should not make it default, because most people need these things. We shouldn't include these in the standard either, since it is purely implementation dependent.

You may want to disable these features for your own preference. And you may develop, use, or recommend a client software that has options to disable these features.

Let me describe them item by item (sorry it's long):

*****

> * Set their Agent to 'DoH client', no matter what browser/library

Usually we need to include the software versions, mainly because older software may contain bugs, we need to take special care of them. (e.g. Some old clients may use the obsolete application/dns-udpwireformat or message/dns MIME types, so we need to be compatible.)

Also, we need to give warning or stop service for certain clients that are known to serious security flaws. Otherwise, the users may not be aware that they need to install security patches.

Third, it is useful if we can give separate error messages for human (browser) and standalone clients. Users may accidentally click into a DoH URL without any intention to do DNS query. Do we need to give them a 400 error, or a 302 redirect to a human-readable help page?

*****

> * Do not pass non-essential HTTP headers (like language)

For browsers, we usually cannot control it through XHR API.

For standalone clients, nobody would send extra headers since that requires extra code.

Since we cannot do anything to change it, I think it is useless to talk about it.

*****

> * Do not allow the DoH server to set cookies

Do you know RFC7873? Yes, there is already a Cookie system for traditional DNS protocol. And many public DNS services are already using it to protect against DDoS attack.

Additionally, since DoH protocol usually relies on Keep-Alive connections (otherwise it would be painfully slow), a single connection usually correspond to a single user or a single group of users, isn't it?

Similar to RFC7873 Cookie, HTTP Cookie also serves as a tool to defend servers from DDoS attacks, and is already widely adapted by many leading CDN providers.

My suggestions is to give the user an option to disable Cookies, or limit Cookies to a very short lifetime (e.g. 2 minutes).

So I think it is better to provide an option instead of making the choice for the user. A "disable Cookie" option is already implemented in my implementation of DoH protocol suite (check below for the software).

*****

> * Ponder TLS sessions resumption data settings

I am not familiar with this protocol. I guess disabling it will make connections much slower? (200x CPU time according to CloudFlare blog.)

Anyhow either enabling or disabling it does not affect security, because again, DoH usually relies on Keep-Alive connections and the user's IP can be tracked.

Since this feature can be turned on or off solely on the client side, you can just use a client that disables this feature, without relying anything from the server.

*****

> * Think about all other ways in which HTTP can be tracked (HSTS?)

I don't think HSTS can be a problem if we always copy-and-paste DoH URLs.

You may run a non-standard DoH server through plaintext HTTP protocol for debugging or other purposes. But we strongly disrecommends using any DoH URL that does not starts with "https:".

*****

Extra A: Keep-Alive and Tor

I just talked about Keep-Alive. Since DoH runs over HTTP/2, Keep-Alive is normally enabled. If you are worried about it, you can run a non-standard DoH client with HTTP/1.0 over HTTPS. Please be warned that this is non-standard, and painfully slow, and burdens the server that may cause your IP to be banned by them.

If you use DoH through Tor, I recommend you try CloudFlare's DoH hidden service. It's fast, secure, and private. (Disclaimer: This is purely a personal recommendation and is not related with any promotional activities)

*****

Extra B: ECS and IP tracking

I consider RFC7871 (EDNS Client Subnet) an important feature with DoH. This protocol is used by many traditional servers to provide geolocationally-near results. Servers without ECS rely on Anycast.

Anycast does not solve all problems, especially for some countries where competing ISPs deprioritize inter-ISP traffic. (e.g. China Mobile -> Hong Kong Mobile has lower ping than China Mobile -> China Telecom)

For DoH, which is TCP traffic, Anycast becomes much more difficult so DoH service providers may want to deploy ECS on their servers. A serious issue emerges since ECS submits part of the client's IP address (/24 or /48) to the authoritative DNS server. Some users like this feature, while others hate it for privacy reasons.

A positive scenario of this feature is one of my user from China deployed a DoH server outside China, submitting a Chinese IP address through ECS protocol so he can enjoy an MITM-less DNS life but can also watch videos without lag from CDN servers located in the same ISP with him. (DNS MITM is deployed country-wide inside China.)

I thought about this feature seriously and decided to provide an option for the user in my own implementation. Good news is that, if disabled, I will even send a flag telling upstreams to turn off any already enabled-by-default ECS features.

*****

Conclusions:

I agree that some users need the features Bert Hubert have just enumerated. But for most of the time, these features would decrease service satisfactory for the users.

Users would not prefer DoH if DoH is much slower, or is not DDoS-resistant, or is not GeoDNS-compliant, or is simply not secure enough (privacy != security).

So let's make them options. The world is colorful if DoH implementations are different from each other: some care about privacy and some do good on lightning speed.

*****

My implementation:

I took my own DoH implementation as an example of providing abundant options for the sake of users' privacy.

If you want to check it and give suggestions to it, please refer to https://github.com/m13253/dns-over-https .


-- 
Best regards,
StarBrilliant