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

[Daniel Migault <[e-mail]>]

Hi  Christian,

Thank you for taking time to review the draft. The current version of the
draft does not consider active attacks. It does not either analyse how
additional privacy can be leveraged from esni. These will be included in
the next version. Thank you for the feed back, that is very well
appreciated.

Yours,
Daniel



On Wed, Nov 6, 2019 at 6:37 PM Christian Huitema <[e-mail]>
wrote:

> 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
>
> --
> Add mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/add
>