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

[Eric Rescorla <[e-mail]>]

In case it wasn't clear, I don't believe that we (Firefox) would want this
either.

-Ekr


On Tue, Sep 1, 2020 at 12:57 PM 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.
>
> 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
>
>
>