Re: [Add] [EXTERNAL] Re: ADD Requirements Draft

[tirumal reddy <[e-mail]>]

On Wed, 2 Sep 2020 at 01:27, Tommy Pauly <[e-mail]> wrote:

> Agreed. From my perspective as a client vendor, I don’t see a likely path
> to consuming this kind of policy. This is one of the reasons I’ve argued
> that we should have in our requirements a limitation that the entity that
> provides DNS should be one that the client already has a relationship
> with—we don’t need any new explanation of policy, we’re relying on existing
> relationships.
>

Existing relationships are definitely useful in certain scenarios but not
in all. For example:

a) I don't think it is possible for every ISP and Enterprise network in the
world to approach each and every Browser and OS vendor to be pre-configured
with network provided encrypted DNS servers.

b) Secure discovery most likely avoids the need to have the discovered DNS
server pre-configured in OS/Browser. However, as we all know secure
discovery is not possible in some deployments. If the discovered server is
not pre-configured, client/user needs to know the resolver information of
the discovered server. In case of insecure discovery, the client should
have checks to avoid connecting to an encrypted DNS server hosted by an
attacker.

Cheers,
-Tiru


>
> Thanks,
> Tommy (Pauly)
>
> On Sep 1, 2020, at 10:11 AM, Tommy Jensen <
> Jensen.Thomas=[e-mail]> wrote:
>
> ekr> Taking a step back here: is there any client with significant usage
> that would be interested in consuming this kind of policy when published by
> a resolver?
>
> Speaking for myself: no. The user either understands the implications and
> has pre-configured a resolver of their choice, or they don't and expect DNS
> to just work. Until DNS server choice is an everyday user concept akin to
> music streaming app choice (or at least wireless network choice), that will
> continue to be the case.
>
> Thanks,
> Tommy
>
> ------------------------------
> *From:* Add <[e-mail]> on behalf of Eric Rescorla <
> [e-mail]>
> *Sent:* Tuesday, September 1, 2020 9:46 AM
> *To:* tirumal reddy <[e-mail]>
> *Cc:* ADD Mailing list <[e-mail]>; Christopher Wood <
> [e-mail]>
> *Subject:* [EXTERNAL] Re: [Add] ADD Requirements Draft
>
>
>
> On Tue, Sep 1, 2020 at 4:10 AM tirumal reddy <[e-mail]> wrote:
>
> Hi Eric,
>
> Please see inline
>
> On Fri, 28 Aug 2020 at 19:08, Eric Rescorla <[e-mail]> wrote:
>
>
>
> On Fri, Aug 28, 2020 at 12:35 AM tirumal reddy <[e-mail]> wrote:
>
> On Thu, 27 Aug 2020 at 18:46, Eric Rescorla <[e-mail]> wrote:
>
>
>
> On Wed, Aug 26, 2020 at 10:15 PM tirumal reddy <[e-mail]> wrote:
>
> Hi Eric,
>
> Please see inline
>
> On Wed, 26 Aug 2020 at 16:50, Eric Rescorla <[e-mail]> wrote:
>
>
>
> As I said when you first proposed this in an ADD meeting, I do not believe
> that anything of this kind is viable.
>
>
> 1. Certificates tied to a legal entity have not been effective, which is
> why browsers are removing EV.
>
>
> The draft does not propose using EV certificates for encrypted DNS
> servers, please see
> https://tools.ietf.org/html/draft-reddy-add-server-policy-selection-05#section-4
> <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Fdraft-reddy-add-server-policy-selection-05%23section-4&data=02%7C01%7CJensen.Thomas%40microsoft.com%7C4f39107a43f8461cc8c808d84e96ac6c%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637345757215760305&sdata=zwTj9VSEumHDnBDlWRQySYQf2lljLOE7aG%2FcNJKWx%2Bk%3D&reserved=0> for
> more details.
>
>
> It proposes something similar, which I expect to have the same drawbacks.
>
>
> 2. There is ample evidence that users do not read privacy policies.
>
>
> The DNS server privacy statement is much more simpler compared to a
> typical privacy statement by a
> content service provider (see
> https://tools.ietf.org/html/draft-ietf-dprive-bcp-op-14#section-6
> <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Fdraft-ietf-dprive-bcp-op-14%23section-6&data=02%7C01%7CJensen.Thomas%40microsoft.com%7C4f39107a43f8461cc8c808d84e96ac6c%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637345757215770297&sdata=Aon0Ne%2FXFeIqNAPGMS5g0t%2FpPaqrg9bs3OTDJzK3wn8%3D&reserved=0>
> ).
>
>
> I don't think that makes it significantly more likely that people will
> read it.
>
>
> Further, automated analysis of a privacy statement is possible using deep
> learning (https://pribot.org/files/Polisis_USENIX_Security_Paper.pdf
> <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpribot.org%2Ffiles%2FPolisis_USENIX_Security_Paper.pdf&data=02%7C01%7CJensen.Thomas%40microsoft.com%7C4f39107a43f8461cc8c808d84e96ac6c%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637345757215770297&sdata=btIZBlgmsG2b9zCE6pSjQt7q%2FteV6HVT8fakqd08sWQ%3D&reserved=0>).
> You can explore polisis and pritbot at https://pribot.org
> <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpribot.org%2F&data=02%7C01%7CJensen.Thomas%40microsoft.com%7C4f39107a43f8461cc8c808d84e96ac6c%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637345757215780290&sdata=DluH1rTl9DL%2Blcmt0nb5jhy9H6i1QyJwGJhBkT3x%2FoM%3D&reserved=0> to
> explore the analysis of privacy statements by several organizations..
>
>
> I took a quick look at this tool and while it appears to be interesting
> work, it does not produce output which I think is likely for users to
> actually assimilate. For instance here is what it does with McAfee's policy:
>
> https://pribot.org/polisis/?company_url=mcafee.com&_id=59d8f9c4e3dd0c4e24555c1d&category=first-party-collection-use
> <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpribot.org%2Fpolisis%2F%3Fcompany_url%3Dmcafee.com%26_id%3D59d8f9c4e3dd0c4e24555c1d%26category%3Dfirst-party-collection-use&data=02%7C01%7CJensen.Thomas%40microsoft.com%7C4f39107a43f8461cc8c808d84e96ac6c%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637345757215780290&sdata=gL%2BUOJ3dykOrd316WbZH5HpswalaWAKHscWQspcHM7w%3D&reserved=0>
>
> We've already run this experiment of machine readable privacy policies
> once with P3P and I don't see a reason to think this will be any different
>
> Taking a step back here: is there any client with significant usage that
> would be interested in consuming this kind of policy when published by a
> resolver? If so, I'd like to hear from them about their needs. If not, it
> doesn't seem worth discussing further.
>
> -Ekr
>
> --
> Add mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/add
>
>
>