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

[Star Brilliant <[e-mail]>]

>> 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
>
>The current draft RECOMMENDS HTTP/2 but does not require it, or
>did I overlook the HTTP/2 requirement elsewhere?
>
>"HTTP/2 [RFC7540] is the minimum RECOMMENDED version of HTTP for use
>with DoH"

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?
I mean, it is nothing better than a DNS-over-TLS-without-session-resumption.



> I agree that data like user-agent strings is helpful for debugging
> and to implement server-side workarounds for client-side bugs or error handling but
> the privacy of users - in a protocol that's primary goal is to provide
> privacy for end users - should be more important than ease-of-debugging
> for us operators of DoH servers.

If you think User-Agent can be a problem, then you shouldn't use TLS either.
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.


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. Oppositely, hiding User-Agent reduces user's security and service availability.



> I guess there is no expectation of unlinkability within multiple
> DNS queries going over a single TCP connection. The concern
> with cookies is more about linking multiple TCP connections
> based on the cookie.

Let me explain my worries: I run a public DoH service. Now it is healthy because few people are using. I am afraid it may receive DDoS attack in the future, so I planned to use Cookie challenge (with 2 minutes lifetime) whenever I got attacked.
What should I do now if I am not allowed to use Cookies?