Re: [Add] ADD Requirements Draft

[tirumal reddy <[e-mail]>]

Hi Eric,

I think you have misunderstood the purpose of the draft. I would like to
clarify the intent:

1) It prevents the client from connecting to an Encrypted DNS resolver
hosted by an attacker. It is useful when the Encrypted
DNS server is insecurely discovered (e.g., using DHCP/RA, SUDN) and the
discovered encrypted
server is not pre-configured in the OS/Browser. It resembles the
Background-Check Model discussed in Sections 5.2 and 5.3 of Remote
attestation procedure (RATS) Architecture
https://tools.ietf.org/html/draft-ietf-rats-architecture-05.

2)It does not require Encrypted DNS servers to use EV certificates.
However, the verifier creating the attestation results
may or may not use EV certificates depending on whether the Encrypted DNS
server will be discovered securely
or insecurely. For example, the verifier need not use EV certificate in the
following scenarios:

a. If the Encrypted DNS server will only be discovered securely (e.g.,
using IKEv2), the verifier need not
    use an OV/EV certificate.

b. Another scenario is bootstrapping a networking device to use the
encrypted DNS server in the local network. Secure Zero Touch Provisioning
(RFC8572) defines a bootstrapping strategy for enabling devices to securely
obtain the required configuration information with no user input. If the
encrypted DNS server is insecurely discovered and not pre-configured in the
networking device, the client can validate the Policy Assertion Token
signature using the owner certificate as per Section 3.2 of RFC8572. In
this case, the owner certificate
need not be an OV/EV certificate.

3. The draft also signals resolver information like whether the resolver
performs filtering, reasons for filtering and
URL to privacy/audit statement. It does not signal any machine-parsable
privacy policy and it does not intend to replace
the privacy statement provided by a legal attorney.  It is helpful in
scenarios where the discovered resolver is not
pre-configured in the OS/Browser. It aligns with the charter of ADD to
"define a mechanism that allows communication of DNS resolver
information to clients for use in selection decisions. This could be part
of the mechanism used for discovery, above."

Hopefully it clarifies for further reviews.

Cheers,
-Tiru

On Thu, 3 Sep 2020 at 06:54, Eric Rescorla <[e-mail]> wrote:

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