Re: [dns-privacy] Datatracker State Update Notice: <draft-ietf-dprive-rfc7626-bis-04.txt>

[Eric Rescorla <[e-mail]>]

On Tue, Apr 7, 2020 at 7:38 AM Sara Dickinson <[e-mail]> wrote:

>
>
> Begin forwarded message:
>
> *From: *Eric Rescorla <[e-mail]>
> *Subject: **Re: [dns-privacy] Datatracker State Update Notice:
> <draft-ietf-dprive-rfc7626-bis-04.txt>*
> *Date: *9 March 2020 at 15:01:09 GMT
> *To: *Sara Dickinson <[e-mail]>
> *Cc: *Brian Dickson <[e-mail]>, "Eric Vyncke
> (evyncke)" <[e-mail]>, "[e-mail]" <
> [e-mail]>, "[e-mail]" <[e-mail]>, "
> [e-mail]" <
> [e-mail]>
>
>
>
> On Mon, Mar 9, 2020 at 3:55 AM Sara Dickinson <[e-mail]> wrote:
>
>
> Reviewing this thread after several weeks I realised we had one final
> comment to still resolve so trimming the reponse to focus on that….
>
> <snip>
>
>
>>>>>
>>>>> The vast majority of users do not change default application-specific
>>>>>> settings and so implicitly accept the application-specific settings for
>>>>>> DNS. As with network resolvers, these resolvers may have strong, medium, or
>>>>>> weak privacy policies depending on the application.  Privacy policies for
>>>>>> these servers may or may not be available and users need to be aware that
>>>>>> privacy guarantees will vary with each application.
>>>>>>
>>>>>> For users to have the ability to inspect and control the
>>>>>> application-specific DNS settings in a similar fashion to the OS DNS
>>>>>> settings, each application must also:
>>>>>>
>>>>>>    o  expose the default settings to the user
>>>>>>
>>>>>>    o  provide configuration options to manually override the default
>>>>>> settings
>>>>>>
>>>>>>    o  provide configuration options to always use the system resolver"
>>>>>>
>>>>>
>>>>> This last point is wrong. The parallel here would be to use the
>>>>> *network provided* resolver, not the system resolver. I would suggest that
>>>>> you be less prescriptive about this and just say "applications will need to
>>>>> provide user-visible options to configure the resolver." I would avoid
>>>>> "must" (even in lower case) because this is a statement of fact, not a
>>>>> normative one.
>>>>>
>>>>
>>>
>>>> No, system resolver is accurate. In addition to not knowing what
>>>> possible resolver is offered by DHCP, the application can't know if DHCP
>>>> (i.e. network provided) is even being used -- the system could be using a
>>>> static choice of resolver, or even other non-DNS resolution services (e.g.
>>>> NIS+).
>>>>
>>>
>>> It turns out that there are at least three options here:
>>>
>>> - Select your own resolver
>>> - Select the resolver *configured into the system* (AIUI this is what
>>> Chrome does).
>>> - Use the system resolver via the conventional API calls.
>>>
>>>
>>> Suggest:
>>>
>>> "For users to have the ability to inspect and control the
>>> application-specific DNS settings in a similar fashion to the OS DNS
>>> settings, each application also needs to:
>>>
>>>    o  expose the default settings to the user
>>>
>>>    o  provide configuration options to manually override the default
>>> settings so that resolution is performed via
>>>           * user specified resolvers
>>>           * the resolvers configured into the system settings
>>>           * the system resolver via conventional API calls
>>>
>>> If all such applications are updated to use the system resolver, as
>>> described in the last bullet point, the device reverts to a single point of
>>> control for all DNS queries."
>>>
>>
>> Hmm.... this seems unduly prescriptive. Perhaps.
>>
>> For users to have the ability to inspect and control the
>> application-specific DNS settings in a similar fashion to the OS DNS
>> settings, each application also needs to expose the default settings
>> to the users and provide a configuration interface to change them.  If
>> this interface includes a setting to use the system resolver, then the
>> device can be reverted to a single point of control for all DNS
>> queries.
>>
>>
>> I think this removes the status quo bias.
>>
>>
>> I’d be OK with removing the sub-second bullet point but I think the other
>> two have specific existing use cases:
>>
>> - ‘change them’ doesn’t explicitly allow for user specified resolvers
>> which all OS’s do
>> - without the option to disable the application-specific resolution a
>> user cannot apply device level controls to their DNS queries (logging,
>> filtering or rules directing different queries to different resolvers) in a
>> way that can be done today.
>>
>
> But this is what I mean by "status quo bias". And in this case, I suspect
> it's not even correct status quo bias because plenty of applications have
> been doing their own name resolution for some time (and of course malware
> will not have settings for this).
>
> As I said before, we should hear from people who implement their own
> resolver….
>
>
> The goal of this text is to enumerate for the end user the privacy
> considerations of using such an application so I propose this text:
>
> "For users to have the ability to manage the application-specific DNS
> settings in a similar fashion to the OS DNS settings, each application also
> needs to expose the default settings to the user, provide a configuration
> interface to change them, and support configuration of user specified
> resolvers.
>
> If all of the applications used on a given device also provide a setting
> to use the system resolver, then the device can be reverted to a single
> point of control for all DNS queries. If not, then (depending on the
> application and transport used for DNS queries) users should take note that
> they may not be able to inspect all their DNS queries or manage them to set
> device wide controls e.g. domain based query re-direction or filtering. “
>

I don't think this addresses my concern, because "revert" implies that this
is somehow the default situation, which, as I said, is not clearly the case
because applications have been doing their own resolution for some time.

In the interest of moving forward, i suggest you change the term "reverted"
to "configured" and add at the end "Note that this does not guarantee
controlling malware name resolution as it can simply ignore whatever the
system resolver and any user configuration settings."


Sara.
>
>
> -Ekr
>
> Sara.
>>
>> That said, I'd like to hear from people
>> who implement their own resolver even for Do53. I know Chrome does
>> this and I believe it's quite common for SIP stacks due to performance
>> concerns with the system resolver.
>>
>> -Ekr
>>
>>