Re: [Add] ADD Requirements Draft

[tirumal reddy <[e-mail]>]

On Thu, 3 Sep 2020 at 20:32, Tommy Pauly <[e-mail]> wrote:

>
>
> On Sep 3, 2020, at 2:23 AM, tirumal reddy <[e-mail]> wrote:
>
> 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."
>
>
> This charter point refers, I believe, to information like applicable or
> private domains, provider identity, etc. I think that filtering policy and
> auditing statements are not in scope: "Making any recommendations about
> specific policies for clients or servers is out of scope.”
>

The draft does not recommend any specific policies for clients or servers.
For example, it does not discuss any "privacy policies'.

a) It explains DNS server identity and cryptographically attesting the
identity.
b) It also discusses whether the server performs filtering, reasons for
filtering (blocking malware/phishing etc.). We are considering the conveyed
resolver information as "resolver capabilities". It does not recommend any
specific policy for the server/client.

-Tiru


>
>

> Thanks,
> Tommy
>
>
> 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
>>>>
>>>> --
> Add mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/add
>
>
>