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

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

On Wed, Nov 6, 2019 at 2:10 PM Tommy Jensen <Jensen.Thomas=
40microsoft.com@dmarc.ietf.org> 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.
>
> Thanks,
> Tommy
> ------------------------------
> *From:* Add <add-bounces@ietf.org> on behalf of Stephen Farrell <
> stephen.farrell@cs.tcd.ie>
> *Sent:* Wednesday, November 6, 2019 6:20 AM
> *To:* Daniel Migault <daniel.migault=40ericsson.com@dmarc.ietf.org>;
> add@ietf.org <add@ietf.org>
> *Subject:* Re: [Add] Fwd: New Version Notification for
> draft-mglt-abcd-doh-privacy-analysis-00.txt
>
>
> Hi Daniel,
>
> On 05/11/2019 20:40, Daniel Migault wrote:
> > Please find an analysis on DoH and privacy. The intent is to provide an
> > 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.
>
> >
> > Yours,
> > Daniel
> > ---------- Forwarded message ---------
> > From: <internet-drafts@ietf.org>
> > 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 <mglt.ietf@gmail.com>
> >
> >
> >
> > 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://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:
> >    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
> >
> >
> --
> Add mailing list
> Add@ietf.org
> https://www.ietf.org/mailman/listinfo/add
>