Re: [Add] ADD Requirements Draft

[Eric Rescorla <[e-mail]>]

Tirumal,

I think this conversation has gone beyond the point where it is productive.

I do not believe that users are going to be able to meaningfully consume
either real world identity information ("This is run by company X") or
privacy policy information about resolvers. We've tried that in several
other domains and it hasn't worked, and I don't think going through why in
a lot of detail is going to illuminate the situation here. But more to the
point, I think you're hearing that client vendors aren't interested, so
standardizing this would not help. If you want to continue to propose this,
I suggest that you find some set of clients which would consume it, at
which point a discussion of the merits of this idea will be more useful.

-Ekr



On Wed, Sep 2, 2020 at 5:32 AM tirumal reddy <[e-mail]> wrote:

> Please see inline
>
> On Tue, 1 Sep 2020 at 22:16, Eric Rescorla <[e-mail]> wrote:
>
>>
>>
>> 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 for
>>> more details.
>>>
>>
>> It proposes something similar, which I expect to have the same drawbacks.
>>
>
> Can you please explain the drawbacks for further discussion ?
>
>
>>
>>
>> 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).
>>>
>>
>> I don't think that makes it significantly more likely that people will
>> read it.
>>
>
> It varies from person to person. People may not read the privacy
> statements because they visit several domains in a day. The DNS operators a
> user will use will be very few, for example an user may want to use a
> discovered resolver in selected networks like Enterprise or Home network.
> Further, encrypted DNS resolver publishing the privacy statement URL is a
> best practise similar to the way OS mandating apps to publish privacy
> policy.
>
>
>>
>>
>> Further, automated analysis of a privacy statement is possible using deep
>>> learning (https://pribot.org/files/Polisis_USENIX_Security_Paper.pdf).
>>> You can explore polisis and pritbot at https://pribot.org 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
>>
>
> The summary page is quite easy for end users to review the
> positives/negatives to watch out for and it also highlights the relevant
> text in a large privacy document (see
> https://pribot.org/polisis/?company_url=http%3A%2F%2Fmcafee.com&_id=59d8f9c4e3dd0c4e24555c1d&category=assessment).
> The DNS server privacy statement is much more simpler compared to a typical
> privacy statement for deep learning to identify if the server is
> privacy-friendly.
>
>
>>
>> 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
>>
>
> No, the draft does not discuss any machine readable privacy policies other
> than conveying the privacy statement URL.
>
>
>>
>> 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.
>>
>
> The draft only discusses conveying resolver information and does not
> discuss any machine parsable privacy policy.
>
> -Tiru
>
>
>>
>> -Ekr
>>
>>