Re: [Add] Fwd: New Version Notification for draft-reddy-dprive-dprive-privacy-policy-00.txt

[Paul Wouters <[e-mail]>]

On Thu, 10 Oct 2019, tirumal reddy wrote:

> I am referring to BYOD devices, BYOD will not have Enterprise root certificate and cannot be provisioned with the
> Enterprise DoT/DoH server using AD. The owner of the the BYOD has a choice whether to use the Enterprise network
> provided DoT/DoH server or not. 

I have a BYOD device. My enterprise insists that they have limited
control via Google Mobile Device Management. They could dictate
to use certain DNS servers when connecting to certain wifi networks.

>       Again, this is fixing a problem that I do not think exists. Why should I
>       trust or not trust this network with DNS to begin with? Their privacy
>       policy update will not change that for me. Either, they were already too
>       weak for me to trust, so I don't care about their DNS privacy policy
>       update, or I trusted them already, in which case it seems I trust them
>       more than my own trusted DNS - AKA I'm forced to trust them (an
>       enterprise network).
> 
> I disagree, user needs to know whether his privacy requirements are met by the local DNS server or public DNS server.

The user cannot know if their privacy requirements are met, with or
without a signed XML statement from those parties. The user can only
hope. And since the user can only hope, it is by far safer to pick
a few or a single trusted party, than to hope each time they connect
to a new wifi network.

> If the public DNS server decides to change the policy to sell user data to third-parties, the user would want to move
> to a different DNS server. 

Sure. But a DNS server that is going to betray the user like that,
wouldn't be stopped by a signed XML file either.

> An end-user cannot audit the privacy claims by any DNS provider including the public DNS revolvers, and can possibility
> rely on the audits performed by third parties (similar to way VPN providers use third party audits).  How does the user
> know the public DNS server has not made false privacy claims ?

The user gains trust through a variety of non-technical, non-protocol
ways. News items, journalism, company reputation, prefering a non-profit
over an advertisetment company, entity history, people they know, etc.
Perhaps even through third party audits similar to mandated CAB/Forum
audits. Why do I not trust Sony or LinkedIn? Because they proved to
not deserve it in the past. Why do I trust cloudflare or PCH? Because
until now, they have proven to commit to their publicly announced
policies on their websites and as reported by other experts.

>       I either have a really good DNS provider that I fully trust up my
>       sleeve, or I don't. If I do, I don't need the local network one.
>       If I don't, I have no choice but the use the local network one.
> 
> Local DNS server for several reasons, blocking malware and phishing

How relevant is this in reality. Linux and OSX people and all mobile
phones do not run anti-malware software. Phising happens mostly via
email, which is unaffected by DoH/DoT and can still be done serverside,
and search engine results - which are curated by both search engines
(google filtering bad stuff) and browsers (eg mozilla preventing me to
go to a known malware site). None of this puts any requirements on my
DNS provider selection.

> , enforce MUD rules to only allow intended
> communications to and from the IoT devices.

non-mobile IoT devices hardly have a use for encrypted DNS to begin
with, and their MUD profiles should not allow it. Those should clearly
state "DNS to DHCP supplied resolver only" and "these domains related to my
services". Note that this isn't secure unless you could trust the DNS
answers, by either local transport or DNSSEC integrity.

> Several other reasons like "CDN endpoint selection" are listed
> in https://tools.ietf.org/html/draft-reid-doh-operator-00

CDN endpoint tracking is pretty risky from a privacy point of view. The
operator might want that, but the user that desires privacy might not.

>       Then why should I ever take a risk that this local network has a privacy
>       policy that does not actually match its implementation?
> 
> Firefox falls back to clear text DNS because the local network has parental control or DNS filtering. Android has an
> option to automatically use to the local DoT server (opportunistic mode). 

Sure, to support the enterprise/parental case voluntarilly. Again, there
is hardly a need to codify this in XML. Their users are forced to
comply. If I am at starbucks, I am not going to let firefox downgrade me
because of "parental control" desire, whether the instructions are XML
signed or not.

>       > Further, it also provides a mechanism to securely signal to the DNS client that the
>       > attached network performs DNS filtering. 
>
>       You cannot signal securely unless I have a trust anchor already on my
>       device that would be used. If this is a CA-type store of hundreds of
>       trust anchors, I cannot really trust them for this decision over a
>       personally selected known safe choice.
> 
> You may want to re-look into the Security and Privacy considerations sections, we are not suggesting to rely on the
> hundreds of trusted anchors on the browser/OS. 

If it is a fundamental design item, it should have its own Section on
how to implement it. Not just waive some Security and Privacy
considerations.

>       If it is enterprise specific,
>       we already have mechanisms in place for securely obtaining updated DNS
>       mechanisms. Like via VPN using RFC 8598.
> 
> No, it is not specific to Enterprise IT manged devices. Managed network security can be provided by ISPs, Home router
> integrated with security service, BYOD policies in Enterprise networks etc. 

ISPs that are not a utility are defacto an enterprise network. Home
routers are parental control or 'enterprise' networks. BYOD devices
already have their methods to enforce various things on their respective
mobile OS platforms requiring no IETF standards. So your cases are still
really enterprise/parental control, where there are tight and mandatory
trust relationships. No signed XML needed.

As I said before, I haven't seen much upside on this. I do see downsides
when this kind of mandatory reconfiguring of my device privacy settings
are being forced at the ISP or national level to circumvent my privacy.
Maybe think of a Human Rights Consideration Section in the document too
as per RFC 8280 ?

Paul