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

tirumal reddy <kondtir@gmail.com> Thu, 10 October 2019 15:03 UTC

Return-Path: <kondtir@gmail.com>
X-Original-To: add@ietfa.amsl.com
Delivered-To: add@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CDF101201DE for <add@ietfa.amsl.com>; Thu, 10 Oct 2019 08:03:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.997
X-Spam-Level:
X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 121YEB5slYh7 for <add@ietfa.amsl.com>; Thu, 10 Oct 2019 08:03:55 -0700 (PDT)
Received: from mail-io1-xd2e.google.com (mail-io1-xd2e.google.com [IPv6:2607:f8b0:4864:20::d2e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0B4E7120123 for <add@ietf.org>; Thu, 10 Oct 2019 08:03:54 -0700 (PDT)
Received: by mail-io1-xd2e.google.com with SMTP id v2so14387849iob.10 for <add@ietf.org>; Thu, 10 Oct 2019 08:03:54 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=6I6uTq26z0mkhlOCMe/GLoiopn9euc/ZIjKtf5GwkPs=; b=bib6tN7HTn2rH7tcmMPA+7IAvkoGhTCwEiUxPAUm1Q/W6mw84g/qjZj2x9f9DnIdZW cIGXUYKMRIVnHTldnajeVynScvqwhrfszWecMP3ZT/NYJMa82rXU4VaAyHhf8jFnaGZB Vp44BQO4I6a0THl/bJOekfqHUIrbeZ0OnivQ3N6Z1xdJd+LzspsaTIsiyl5O0qZXJgIZ 2ZuzeBUsmhgP4RbhrBlgJZa9+E3QwcH4qdOj5cGh7HWQS1kxp9wZWQb6kRfeILALOVRr +EquefZaiNNF1tg9RpYiDAKr1z/hUip/Zr+yL1xCMu+RbS0qnuROsj+ZR2G5jnUEk/pi s+Ag==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=6I6uTq26z0mkhlOCMe/GLoiopn9euc/ZIjKtf5GwkPs=; b=p7jiPMf3Ql9yNyjHA4VFGscEAyYAecGoln41DoFZvOlMPMcb2MihWR3xqyJEmC1pux KqPz8duCqgevVtcwS9Ani9JfNUa7x4nbhgx2rOuFDVYvxmVNJLCKAijXD12z6r8OCFUK V+lXq9SLqU0LkH7v98f9UwE8XbHXulB441NE00M/aFNZrZi3BuqEW5rZo/3Xa0dgBwiY g5ysWVok7PUMgbf55RGTnBjHEn7YYfDP8dfEGKM9Tn3Rgxd/8D1ROulo6E6sOiaMOaNk z3+dY6wMWYs7ly2IfJkGTCYsHix/dqUfW4q0avyfWJDb5Q22tH7PD185bFmDUiPPbPn+ 5Cww==
X-Gm-Message-State: APjAAAUDwTUKpFBgohA2p+Qmo0H2wkAHngshyjLb/VNpQaxOKcO1o9Bt KTdJ6Ck7zXeF+BQYWjZhlITVsuhhVB7vcrPVO29wM8N4
X-Google-Smtp-Source: APXvYqxLZAT88rWwSco5Hylx7iVnfg9HT0GZgf85qWLw4beRNPS9ob+GfUal8CLHU2/WJx9XXjWvMr/FV/ofVFDV1T4=
X-Received: by 2002:a6b:5814:: with SMTP id m20mr10833394iob.242.1570719834202; Thu, 10 Oct 2019 08:03:54 -0700 (PDT)
MIME-Version: 1.0
References: <157009854908.16293.4269133049514081713.idtracker@ietfa.amsl.com> <CAFpG3gdpYASvfz_ey=fsh6+8LQ11EJGyU-dVxH7_1QmVeiAQKg@mail.gmail.com> <alpine.LRH.2.21.1910051351420.26913@bofh.nohats.ca> <CAFpG3gfLLkdZt-b+r=8RY8a+yoJx2tzQOevnOLkNQSm9g9QuDw@mail.gmail.com> <alpine.LRH.2.21.1910070925260.8046@bofh.nohats.ca> <CAFpG3ge=zF0W1PzZjc=ysxVzir4tMVa=8ZHs5qyxg4NbE73SPw@mail.gmail.com> <alpine.LRH.2.21.1910090954170.30131@bofh.nohats.ca>
In-Reply-To: <alpine.LRH.2.21.1910090954170.30131@bofh.nohats.ca>
From: tirumal reddy <kondtir@gmail.com>
Date: Thu, 10 Oct 2019 16:03:41 +0100
Message-ID: <CAFpG3gesT5jnCgjUaSH0KFVTNGFsVPo8D5tcgwnF1Y+u6ShQ4w@mail.gmail.com>
To: Paul Wouters <paul@nohats.ca>
Cc: ADD Mailing list <add@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000c26c3605948fb593"
Archived-At: <https://mailarchive.ietf.org/arch/msg/add/Ke4R0MBLoDFJkB1L1J1Yax_JbDI>
Subject: Re: [Add] Fwd: New Version Notification for draft-reddy-dprive-dprive-privacy-policy-00.txt
X-BeenThere: add@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Applications Doing DNS <add.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/add>, <mailto:add-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/add/>
List-Post: <mailto:add@ietf.org>
List-Help: <mailto:add-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/add>, <mailto:add-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 10 Oct 2019 15:04:10 -0000

On Wed, 9 Oct 2019 at 15:05, Paul Wouters <paul@nohats.ca> wrote:

> On Tue, 8 Oct 2019, tirumal reddy wrote:
>
> >       How and how would any enforcement system work for a variety of DNS
> >       providers all over the world? ISPs? hotels? coffeeshops? Mobile
> >       providers? Will there be an industry standard org? How will this
> >       not devolve into government sanctioned mandatory DNS providers on
> >       my mobile device?
> >
> > Users may or may not trust the attached network and the DNS server
> provided by the network (e.g, a public
> > network). It is similar to the way users disable VPN in specific trusted
> networks (e.g., Enterprise network)
> > and VPN is enabled by default in all other networks.
>
> The user can already do that, without any help from the local network.
> If someone configures a VPN or a DoT/DoH, they do not need the local
> network for anything except passing a captive portal. I don't understand
> what you are adding here.
>
> Trust relationships of networks are:
>
> 1) I don't need to trust them, so I don't
> 2) I am forced to trust them, so I do.
>
> In the case of an enterprise network like 2) they can already
> pre-install the CA certs I need to trust on connecting to the
> network (see the IETF network do something similar there)
>

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.


>
> > No. If the privacy requirements of the endpoint are not met, the DNS
> client can discard using the discovered
> > DNS server in the attached network, and connect to a public DNS resolver
> meeting the endpoint privacy
> > preserving data policy requirements.
>
> Again, it is the other way around. Users should not need or want to
> trust the local network. My laptop mostly connects to completely unknown
> networks with zero trust _or_ a trusted enterprise network. What are
> these networks that a user should "trust to filter or log their DNS for
> them" ?
>

> > The proposed mechanism also helps the DNS client to automatically learn
> updates to the privacy claims by a DNS
> > server and avoids the need for users to periodically manually review the
> privacy statement.
>
> 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. 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.


>
> > The privacy policy information helps make the decision whether the DNS
> provider can be trusted or not.
>
> No it does not. It can only tell me when I for sure cannot trust them.
> Since I did not audit their logging, I can never be sure to trust them.
>

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 ?


>
> It's like saying a privacy policy will select whether I use HTTP:// or
> HTTPS://. That is not the question. The question is why would I ever
> use HTTP:// ?
>

> >       I'm still not convinced this statement is wrong. And additionally
> can
> >       see some serious harmful effects into mandatory censorship if this
> kind
> >       of system becomes mandatory on people's devices.
> >
> > I disagree, the proposal helps the user to choose a DNS server that best
> supports the desired privacy
> > policies.
>
> 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,
enforce MUD rules to only allow intended communications to and from the IoT
devices. Several other reasons like "CDN endpoint selection" are listed in
https://tools.ietf.org/html/draft-reid-doh-operator-00


>
> > DNS clients do not need to fallback to clear text DNS, and can use the
> DoT/DoH server provided by
> > the local network.
>
> 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).


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

Cheers,
-Tiru


>
> Paul
>