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

[tirumal reddy <[e-mail]>]

On Thu, 10 Oct 2019 at 16:44, Paul Wouters <[e-mail]> wrote:

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

No, Enterprise BYOD policy may not mandate MDM on the device. On the other
extreme, Enterprise BYOD policy can mandate the MDM on the BYOD to install
Enterprise root certificate.


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


No, the proposed mechanism conveys signed privacy policy information to the
DNS client and the privacy policy contains a URL that points to the human
readable privacy policy formation of the DNS server. The privacy policy can
also be signed by a third party who performed privacy and security audit of
the DoT/DoH server.

Most importantly, user has to select specific networks to learn the privacy
claims of local DoT/DoH server and user
consent is required to use a locally-discovered DoT/DoH server. Further,
the client can learn updates to the privacy claims by the public DNS
server, and the user does not have to periodically manually review the
privacy statement of the DNS server.


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

The draft is not proposing to select the local DoT/DoH server in all
connected networks, see
https://tools.ietf.org/html/draft-reddy-dprive-dprive-privacy-policy-00#section-9


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

The point is the DNS provider becomes liable to penalties and will act as a
deterrent to lie (similar to the way FTC has imposed fine on Facebook).


>
> > 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 suggest we stick the discussion to technical points, ISPs and Enterprise
networks can also publish DNS privacy policies. If you look into the
privacy claims from popular public DNS resolvers (see
https://dnsprivacy.org/wiki/display/DP/Comparison+of+policy+and+privacy+statements),
several claims like client IP address is not treated as PII, client IP
address is logged and identifiable data shared with partners may not meet
the privacy requirements of the user.


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


It is very much relevant today, Android and Windows run anti-malware
software, and the operating systems are suseptible to several attacks
including ransomware, crypto mining, data leakage etc. Several working
groups at IETF discuss endpoint and network security (sacm, i2snf, sfc,
dots etc.). On a side note, recently malware is discovered on iPhone, see
https://blog.malwarebytes.com/mac/2019/08/unprecedented-new-iphone-malware-discovered/
.


> Phising happens mostly via
> email, which is unaffected by DoH/DoT and can still be done serverside,
>

No, see https://news.gandi.net/en/2019/07/how-to-fight-dns-hijacking/


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

Several networks today use network security to filter malware, and do not
rely on the browser filtering capability.
What is the efficacy of these browsers to block malware sites ?


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

The DNS requests from IoT devices are also privacy sensitive. For example,
domain names can be used to identify the IoT device type, make and model.
IoT devices would want to use DoT/DoH server capable of enforcing MUD rules
based on domain names.


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

The users may desire both privacy and performance, public revolvers like
google and opendns support edns-client-subnet.


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


An attacker can spoof NXDOMAIN response to the canary domain, and the DNS
client will assume the network performs DNS filtering, and falls back to
clear text DNS. Further, the client does not know the privacy claims of the
network performing DNS filtering, and when the client falls back to clear
text DNS, DNS messages are susceptible to pervasive monitoring and spoofed
responses.

The proposed mechanism allows the client to use the local DoT/DoH server,
and avoids the need to fall back to clear text DNS.


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

I don't think Firefox prompts the user to decide whether the DNS client can
fallback to clear text DNS or not. Anyways, our proposal expects user
consent is obtained to use the discovered DoT/DoH server.

Further, as discussed in
https://tools.ietf.org/html/draft-grover-add-policy-detection-00 it seems
network operator can mandate its resolver to be used as a condition of
using the network.


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

Sure, will add a new section.



> >       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 have explained previously BYOD with MDM is not used in several
Enterprise deployments and I have not seen MDM used by Home network
security. The proposal equips both the DNS client and user to learn the
privacy claims by the DNS server (both local and public) and choose to use
the DNS server or not.


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

I disagree, the draft is not proposing re-configuring the device privacy
settings. The client learns the DNS server privacy claims, and decides
whether to use the server or not.  The intent of the draft is meet the
user's privacy requirements, and not to circumvent them. The proposed
mechanism also helps the DNS client to automatically learn updates to the
privacy claims by a public DNS server and avoids the need for users
to periodically manually review the privacy statement.

Maybe think of a Human Rights Consideration Section in the document too
> as per RFC 8280 ?
>

I don't understand why the above Section is required in the first place ?
If you can propose text, we can evaluate and update the draft.

Cheers,
-Tiru


>
> Paul
>