Re: [Add] ADD Requirements Draft

[tirumal reddy <[e-mail]>]

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