Re: [Add] Fwd: New Version Notification for draft-mglt-abcd-doh-privacy-analysis-00.txt

[Christian Huitema <[e-mail]>]

On 11/6/2019 12:50 PM, Vittorio Bertola wrote:

> Regarding Daniel's draft, I appreciate the effort and I partly tried
> to do this and other analyses in my draft for Prague, but I then
> realized that there are people here that will never consent to such a
> document becoming an agreed standard, even if informational. So I
> suggest that we should focus on a few technical developments for
> interoperability purposes that we can agree upon, such as standardized
> ways for the local network to advertise their own Do* service and
> their use of it for local policy enforcement, and give up discussions
> on deployment models and human rights assessments. I don't think we
> could ever get to agreement here on whether DoH brings more privacy
> and freedom or less of it, as the answer is really "it depends". 


Daniel's draft is certainly biased towards Daniel's opinions. For
example, I don't buy his assertion that replacing the OS defaults by app
decisions is always unfriendly to privacy. It is very easy to find
counter-examples. But there are a couple of facts that we should
acknowledge:

1) In general, the local network can retrieve the name of the server by
looking at the traffic. This is obvious when the communication happens
in clear text. It is also true if the traffic is encrypted using TLS
versions 1.2 or lower, because the server certificate is carried in
plain text. And it is still true if using TLS 1.3 but the SNI is not
encrypted.

2) Because of that, in general, sending the DNS request to a third party
resolver can only result in a loss of privacy. Even if the third party
resolver has a virtuous approach to privacy, the fact remains that in
general information that was present in just one place is now present in
two, and that cannot be described as a gain.

3) But of course there are exceptions to this general rule, specifically
when the traffic uses TLS 1.3 and ESNI. That's where Daniel's draft is a
bit weak. It develops the arguments (1) and (2), but stops there and
does not recognize the exceptions.

One first exception happens when the DNS requests to the local resolver
are not encrypted. This does not create a privacy leak against passive
attackers, because the passive attacker that sees the DNS traffic most
likely also sees the data traffic, as discussed in (1). However,
encryption also protects against active attacks in which the attacker
sends spoofed DNS responses. Using a third party encrypted server in
this scenario is a trade-off between security and slightly worse privacy
(point 2).

Another exception happens when the traffic uses TLS 1.3 and ESNI. In
that case, traffic analysis only reveals a communication with the
fronting server, while DNS queries reveal the hidden server. Resolving
the ESNI record through a trusted third party resolver will hide the
hidden service name from the local network, and that is indeed a gain in
privacy.

It is possible to extend this privacy advantage in two ways:

1) The client could obtain the ESNI record (or equivalent HTTPSVC
record) through other paths than the DNS, e.g. during prior connections
with the hidden service.

2) If the client has cached the content of the ESNI record (or
equivalent HTTPSVC record), it knows in advance the name of the fronting
server. If the client has not also cached the address, it will get
better privacy by looking up the fronting server name through the local
resolver. That will prevent providing the third party service with
information about timing of connections from the client.

-- Christian Huitema