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

[tirumal reddy <[e-mail]>]

Hi Tommy,

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

>
>
> On Sep 3, 2020, at 3:10 AM, tirumal reddy <[e-mail]> wrote:
>
> On Wed, 2 Sep 2020 at 01:27, 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.
>>
>
> Existing relationships are definitely useful in certain scenarios but not
> in all. For example:
>
> a) I don't think it is possible for every ISP and Enterprise network in
> the world to approach each and every Browser and OS vendor to be
> pre-configured with network provided encrypted DNS servers.
>
>
> It’s not about the relationship of the OS or the browser with the entities
> that can provide DNS services, it’s the relationship of the *user* with
> those entities.
>

Agreed.



> I do not want to have any pre-configuration for any resolver in my OS.
>

Glad to hear. The benefit of conveying the privacy URL is the user does not
have to search to find the URL that points to the human-readable privacy
policy information of the DNS server. The other advantage is if the user
does not have the time/knowledge to understand the human-readable privacy
policy information of the DNS server, user can rely on tools which use AI
to provide summary of the policy (e.g.,
https://addons.mozilla.org/en-US/firefox/addon/polisis/).

It is very similar to Apple mandating apps to provide a link to the privacy
policy in an easily accessible manner within the app for users. It does not
discuss signaling any machine-parsable privacy policy and it does not
intend to replace the privacy statement provided by a legal attorney.

Why do you object to providing a privacy statement URL as resolver
information to the user/client ?


>
>
> b) Secure discovery most likely avoids the need to have the discovered DNS
> server pre-configured in OS/Browser. However, as we all know secure
> discovery is not possible in some deployments. If the discovered server is
> not pre-configured, client/user needs to know the resolver information of
> the discovered server. In case of insecure discovery, the client should
> have checks to avoid connecting to an encrypted DNS server hosted by an
> attacker.
>
>
> Secure discovery—or at least authenticated discovery over a secure
> channel—is indeed the right way to do things. We should be designing and
> standardizing mechanisms that raise the bar for security over the status
> quo, and ensure that we are not making avenues of attack easier.
>

Agreed, secure discovery is possible in several scenarios like VPN (e.g.,
using IKEv2 Configuration Payload ), Enterprise networks for BYOD (e.g.,
EST) but not possible home networks.
https://tools.ietf.org/html/draft-btw-add-home-08#section-10 discusses how
all the threats in RFC3552 can be addressed in the presence of insecure
discovery.

Cheers,
-Tiru


>
> Tommy
>
>
> Cheers,
> -Tiru
>
>
>>
>> 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
>>
>>
>>
>