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

From: Daniel Migault <[email-masked]>
Date: Tue, 5 Nov 2019 15:40:59 -0500

Please find an analysis on DoH and privacy. The intent is to provide an
analysis. Any feed backs are welcome!

Yours,
Daniel
---------- Forwarded message ---------
From: <[email-masked]>
Date: Mon, Nov 4, 2019 at 11:20 AM
Subject: New Version Notification for
draft-mglt-abcd-doh-privacy-analysis-00.txt
To: Daniel Migault <[email-masked]>

A new version of I-D, draft-mglt-abcd-doh-privacy-analysis-00.txt
has been successfully submitted by Daniel Migault and posted to the
IETF repository.

Name:           draft-mglt-abcd-doh-privacy-analysis
Revision:       00
Title:          A privacy analysis on DoH deployment
Document date:  2019-11-04
Group:          Individual Submission
Pages:          11
URL:
https://www.ietf.org/internet-drafts/draft-mglt-abcd-doh-privacy-analysis-00.txt
Status:
https://datatracker.ietf.org/doc/draft-mglt-abcd-doh-privacy-analysis/
Htmlized:
https://tools.ietf.org/html/draft-mglt-abcd-doh-privacy-analysis-00
Htmlized:
https://datatracker.ietf.org/doc/html/draft-mglt-abcd-doh-privacy-analysis

Abstract:
   This document provides an analysis on DoH impact on privacy

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat

---

From: Rob Sayre <[email-masked]>
Date: Tue, 5 Nov 2019 13:34:32 -0800

> analysis. Any feed backs are welcome!

One aspect I've found common to criticisms of DoT and DoH is that they tend
to focus on "privacy", which I take to mean confidentiality. It's true that
these encrypted transports might not provide confidentiality, since the
information in the query can currently leak in several ways.

However, DoT and DoH do provide message integrity between the client and
the selected resolver. It's difficult to argue that this property is a bad
thing.

thanks,
Rob

---

From: Alec Muffett <[email-masked]>
Date: Tue, 5 Nov 2019 22:38:33 +0000

On Tue, 5 Nov 2019 at 21:34, Rob Sayre <[email-masked]> wrote:

> One aspect I've found common to criticisms of DoT and DoH is that they
> tend to focus on "privacy", which I take to mean confidentiality.. It's
> true that these encrypted transports might not provide confidentiality,
> since the information in the query can currently leak in several ways.
>

This; it's a curious blind spot, similar to the perennial "Why would
{Facebook*, NYTimes, BBC} run a Tor Onion site?" question.

Answer: security models contain more than {anonymity, privacy} and (in the
latter case) Tor Onion Networking offers benefits like integrity and
assurance of to whom you are connected.

Assurances which DoH also affords over Do53, specifically.

    -a

* https://www.wired.com/2014/10/facebook-tor-dark-site/

-- 
http://dropsafe.crypticide.com/aboutalecm

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 6 Nov 2019 14:20:15 +0000

Hi Daniel,

> analysis. Any feed backs are welcome!

My feedback:

- I don't see how this adds to the discussion. ISTM this
is yet another one-sided description of the issues. What do
you think is the added benefit of having this text in an
Internet-draft? Honestly, I don't get it.

- In particular, I don't think your "conclusion" that "the
overall picture of concentration shows that it represents
a threat to the end user's privacy" can be justified based
on the content. I'm assuming "represents a threat" is not
just weasel-wording for "might be" which is trivially
true. If you mean anything stronger than "might be" then
that's not justified IMO and if you mean "might be" or
anything weaker, then it looks like stretching to find
a pejorative way to describe things.

Cheers,
S.

PS: In saying the above, I do think there are dangers in
how DoH deployments might increase centralisation. But I
also think that one-sided descriptions of those dangers
make the conversations more, and not less, difficult.

---

From: Tommy Jensen <[email-masked]>
Date: Wed, 6 Nov 2019 19:10:20 +0000

Hey Daniel,

Adding onto Stephen's comments (+1 to not sure what the goal of this document is), I'll point out a reoccurrence of the common but false assumption that DoH always means browsers and always means centralization:

draft>> DoH changes this paradigm in the way that an application can circumvent the policy set by the end user, without the end user being aware of it.  Firstly, the encryption is performed by the application and as such does not provide any visibility to the operating system.

DoH doesn't change this paradigm at all, as it isn't a protocol just for apps (see the Adaptive DNS proposal for an example of a platform providing DoH). This problem (apps doing their own DNS and circumventing system configured policy) existed before and continues to exist with classic DNS; it just so happened that the traffic was plain text so any network sniffing software could observe and possibly modify or block it. I consider that an unfortunate side effect of plain text protocols, not a feature we should be working to preserve. It's not like apps doing their own DNS queries today are visible to most users today, who don't know what packet inspection is.

I think if we drive widespread adoption of encrypted DNS protocols by platforms and ISPs, we'll have better luck convincing well-behaved applications to defer to platform configurations than any other approach. After all, why build per-app experiences if the platform experience is already "good" in the eyes of the privacy conscious? This will address the concern of centralization of the DNS as well (which is not an inherent DoH problem, but an inherent "default provider for all customers of X app/platform" problem).

As far as ill-behaved applications go, they were going to do whatever they wanted anyway, and pushing DoH adoption doesn't give them powers they didn't already have. At some point, the problem becomes one of the user needing to decide what apps they trust which we cannot help with via protocol design.

Thanks,
Tommy
________________________________
From: Add <[email-masked]> on behalf of Stephen Farrell <[email-masked]>
Sent: Wednesday, November 6, 2019 6:20 AM
To: Daniel Migault <daniel.migault=[email-masked]>; [email-masked] <[email-masked]>
Subject: Re: [Add] Fwd: New Version Notification for draft-mglt-abcd-doh-privacy-analysis-00.txt

Hi Daniel,

My feedback:

Cheers,
S.

> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Finternet-drafts%2Fdraft-mglt-abcd-doh-privacy-analysis-00.txt&amp;data=02%7C01%7CJensen.Thomas%40microsoft.com%7Ce85f2b5a2eec4a50d4de08d762c47bcc%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637086471402836031&amp;sdata=w7GwUhz%2BIVSB5VW%2BtyEKvAUjTTh%2BNhq12tpVbM5Zw0o%3D&amp;reserved=0
> Status:
> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-mglt-abcd-doh-privacy-analysis%2F&amp;data=02%7C01%7CJensen.Thomas%40microsoft.com%7Ce85f2b5a2eec4a50d4de08d762c47bcc%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637086471402836031&amp;sdata=XmWL4PabqWROpOd1YmGsKfQ9ucjP16tanC5PnTuewAw%3D&amp;reserved=0
> Htmlized:
> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Fdraft-mglt-abcd-doh-privacy-analysis-00&amp;data=02%7C01%7CJensen.Thomas%40microsoft.com%7Ce85f2b5a2eec4a50d4de08d762c47bcc%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637086471402836031&amp;sdata=tpXDCA5qibyJU0%2FBcvkCHxRoKhWTZYi9s4fln0MQLx8%3D&amp;reserved=0
> Htmlized:
> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-mglt-abcd-doh-privacy-analysis&amp;data=02%7C01%7CJensen.Thomas%40microsoft.com%7Ce85f2b5a2eec4a50d4de08d762c47bcc%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637086471402836031&amp;sdata=l4GflUzS14Z68kdSWxLzCjIYKoHWtY%2BwxFxCO5FY%2FEY%3D&amp;reserved=0
>
>
> Abstract:

---

From: Bob Harold <[email-masked]>
Date: Wed, 6 Nov 2019 14:35:16 -0500

On Wed, Nov 6, 2019 at 2:10 PM Tommy Jensen <Jensen.Thomas=
[email-masked]> wrote:

> Hey Daniel,
>
> Adding onto Stephen's comments (+1 to not sure what the goal of this
> document is), I'll point out a reoccurrence of the common but false
> assumption that DoH always means browsers and always means centralization:
>
> draft>> DoH changes this paradigm in the way that an application can
> circumvent the policy set by the end user, without the end user being aware
> of it.  Firstly, the encryption is performed by the application and as such
> does not provide any visibility to the operating system.
>
> DoH doesn't change this paradigm at all, as it isn't a protocol just for
> apps (see the Adaptive DNS proposal for an example of a platform providing
> DoH). This problem (apps doing their own DNS and circumventing system
> configured policy) existed before and continues to exist with classic DNS;
> it just so happened that the traffic was plain text so any network sniffing
> software could observe and possibly modify or block it. I consider that an
> unfortunate side effect of plain text protocols, not a feature we should be
> working to preserve. It's not like apps doing their own DNS queries today
> are visible to most users today, who don't know what packet inspection is.
>
> I think if we drive widespread adoption of encrypted DNS protocols by
> platforms and ISPs, we'll have better luck convincing well-behaved
> applications to defer to platform configurations than any other approach.
> After all, why build per-app experiences if the platform experience is
> already "good" in the eyes of the privacy conscious? This will address the
> concern of centralization of the DNS as well (which is not an inherent DoH
> problem, but an inherent "default provider for all customers of X
> app/platform" problem).
>
> As far as ill-behaved applications go, they were going to do whatever they
> wanted anyway, and pushing DoH adoption doesn't give them powers they
> didn't already have. At some point, the problem becomes one of the user
> needing to decide what apps they trust which we cannot help with via
> protocol design.
>

I agree with most of your points - but here you say "pushing DoH adoption
doesn't give them powers they didn't already have".  One concern is IF some
major web service enables DoH on a major web server, then that does make it
very easy for apps to hide their DNS in a way they could not easily do
before.

-- 
Bob Harold

>
> Thanks,
> Tommy
> ------------------------------
> *From:* Add <[email-masked]> on behalf of Stephen Farrell <
> [email-masked]>
> *Sent:* Wednesday, November 6, 2019 6:20 AM
> *To:* Daniel Migault <daniel.migault=[email-masked]>;
> [email-masked] <[email-masked]>
> *Subject:* Re: [Add] Fwd: New Version Notification for
> Add mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/add
>

---

From: Vittorio Bertola <[email-masked]>
Date: Wed, 6 Nov 2019 21:50:55 +0100 (CET)

Il 6 novembre 2019 20:35 Bob Harold <[email-masked]> ha scritto:

I agree with most of your points - but here you say "pushing DoH adoption doesn't give them powers they didn't already have".  One concern is IF some major web service enables DoH on a major web server, then that does make it very easy for apps to hide their DNS in a way they could not easily do before.

More generally, applications could already do their own DNS-over-whatever-type-of-encryption-and-obfuscation-protocol, but they would have to develop it on their own and also develop and run the related server. After standardizing DoH and getting it widely adopted, applications that want to reach that objective just need to deploy a readily available Web client library and use any of the many public servers - something that any script kiddie can do.

Note that this is less true of DoT, since DoT towards out-of-perimeter servers would more easily be detectable and blockable. This is why I have heard some cybersecurity people suggest that the industry should promote DoT rather than DoH, as they see it less likely that DoT will circumvent national cybersecurity practices and law enforcement mechanisms.

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

--

Vittorio Bertola | Head of Policy & Innovation, Open-Xchange
[email-masked]
Office @ Via Treviso 12, 10144 Torino, Italy

---

From: Daniel Migault <[email-masked]>
Date: Wed, 6 Nov 2019 16:25:37 -0500

Hi Stephen,

Thank you for the feed back and taking the time to read the draft.

To answer to your question, the purpose of this draft is to provide an
analysis of the privacy impact of the deployment of DoH. In that sense it
addresses two of your concerns -- "this is yet another one-sided
description of the issues."--, that is:
* 1) clarification of (potential) issues - and the context in which there
may be issues.
* 2) misleading communications

It seems, at least to me, two valid reasons for having the analysis as an
internet draft.

Regarding your comment, as the author whose english is not his native
language, I can guarantee there is no intention of carrying a pejorative
meaning nor that the document being one sided. For instance, the term
"threat" was used as in a similar way as in RFC6973 [1].

"""
   Although recipients, intermediaries, and enablers may not generally
   be considered as attackers, they may all pose privacy threats
   (depending on the context) because they are able to observe, collect,
   process, and transfer privacy-relevant data.
"""
The cambridge dictionnary [2] provides for threat "A threat of rain is in
today’s forecast." and I do not see any intention of being pejorative as
well.

Comments regarding the content of the draft are more than welcome as usual!

Yours,
Daniel

[1] https://tools.ietf.org/html/rfc6973#section-5.1.1
[2] https://dictionary.cambridge.org/dictionary/english/threat?q=threat+

---

From: Daniel Migault <[email-masked]>
Date: Wed, 6 Nov 2019 16:38:14 -0500

Hi Tommy,

Thanks for the comment. Please see my response to Stephan for the goal of
the document.

I do not think the document states that DoH always means centralization.
Second I do not see that the document points at web browser especially. The
term "browser" is never mentioned - which suprises me as well - , the
reason is that  "DNS client" and "DNS resolver" were used to avoid this
exact confusion. This remains true that the DNS client is inside the
browser or not and in both case this is an application. I think what you
are saying is that your OS DNS Client could use DoH as well. If so yes, I
agree and the document does not try to say otherwise.

This centralized OS resolver application is also where the system DNS
policy is enforced. I think the draft details clearly that this may or may
not represent the end user's DNS policy and in which cases the end user's
policy is enforced. The ability to let the end user enforce his policy is a
primary concern regarding privacy and doing otherwise represents a threat
to privacy.

That applications could already exfiltrate traffic and will do with or
without DoH. These application were even trusted applications or malwares,
not common applications. DoH provides the infrastructure for both of them.

As always comments are welcome!

Yours,
Daniel

---

From: Daniel Migault <[email-masked]>
Date: Wed, 6 Nov 2019 16:45:50 -0500

Hi Vittorio,

I agree that it will be hard to have a general statement as DoH brings more
or less privacy. As you mention "it depends". However, I believe
it should documented, so the end user can understand in which context he is
and what to do.

Yours,
Daniel

On Wed, Nov 6, 2019 at 3:51 PM Vittorio Bertola <vittorio.bertola=
[email-masked]> wrote:

> More generally, applications could already do their own
> DNS-over-whatever-type-of-encryption-and-obfuscation-protocol, but they
> would have to develop it on their own and also develop and run the related
> server. After standardizing DoH and getting it widely adopted, applications
> that want to reach that objective just need to deploy a readily available
> Web client library and use any of the many public servers - something that
> any script kiddie can do.
>
> Note that this is less true of DoT, since DoT towards out-of-perimeter
> servers would more easily be detectable and blockable. This is why I have
> heard some cybersecurity people suggest that the industry should promote
> DoT rather than DoH, as they see it less likely that DoT will circumvent
> national cybersecurity practices and law enforcement mechanisms.
>
> 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".
>
> --
>

---

From: Christian Huitema <[email-masked]>
Date: Wed, 6 Nov 2019 15:34:07 -0800

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

---

From: Daniel Migault <[email-masked]>
Date: Thu, 7 Nov 2019 13:22:51 -0500

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

---

From: Rob Sayre <[email-masked]>
Date: Thu, 7 Nov 2019 10:47:26 -0800

> One first exception happens when the DNS requests to the local resolver

...

Another exception happens when the traffic uses TLS 1.3 and ESNI.

There are other exceptions. For example, the SNI might not match the Host
header in encrypted HTTP traffic.

It could be something completely mismatched, or it could be a more specific
subdomain of the host given in the SNI.

thanks,
Rob

---

From: Christian Huitema <[email-masked]>
Date: Thu, 7 Nov 2019 11:36:23 -0800

On 11/7/2019 10:47 AM, Rob Sayre wrote:

> On Wed, Nov 6, 2019 at 3:37 PM Christian Huitema <[email-masked]
> <mailto:[email-masked]>> wrote:
>
> There are other exceptions. For example, the SNI might not match the
> Host header in encrypted HTTP traffic.
>
> It could be something completely mismatched, or it could be a more
> specific subdomain of the host given in the SNI.

There may very well be other exceptions. I think that we should document
them, so we can properly discuss the various trade-off.

As for the HTTP Host vs SNI scenario, that's of course one possible
exception. Possible, because it depends whether the DNS lookup is for
the SNI or the SNI host. If the former, then it is not an exception:
doing a lookup for the SNI would not reveal anything that could not be
inferred from looking at the traffic. But looking for the inner host in
the DNS would indeed reveal that, in the same way that looking at the
ESNI does.

-- Christian Huitema

---

From: Rob Sayre <[email-masked]>
Date: Thu, 7 Nov 2019 15:40:01 -0800

> them, so we can properly discuss the various trade-off.

I agree that discussions are fine, but I disagree that this document is
close to being useful. I guess I think that a somewhat useful document will
get very close to documenting the security properties of TLS and HTTPS
themselves, with some mention of in-progress work, like ESNI and QUIC/HTTP3.

thanks,
Rob