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

From: Sara Dickinson <[email-masked]>
Date: Tue, 7 Apr 2020 15:38:12 +0100

> Begin forwarded message:
> 
> From: Eric Rescorla <[email-masked]>
> 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 <[email-masked]>
> Cc: Brian Dickson <[email-masked]>, "Eric Vyncke (evyncke)" <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
> 
> 
> 
> On Mon, Mar 9, 2020 at 3:55 AM Sara Dickinson <[email-masked] <mailto:[email-masked]>> 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. “

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

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 7 Apr 2020 08:23:24 -0700

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

>
>
> Begin forwarded message:
>
> *From: *Eric Rescorla <[email-masked]>
> *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 <[email-masked]>
> *Cc: *Brian Dickson <[email-masked]>, "Eric Vyncke
> (evyncke)" <[email-masked]>, "[email-masked]" <
> [email-masked]>, "[email-masked]" <[email-masked]>, "
> [email-masked]" <
> [email-masked]>
>
>
>
> On Mon, Mar 9, 2020 at 3:55 AM Sara Dickinson <[email-masked]> 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.
>>>>>>
>>>>>> settings, each application must also:
>>>>>>
>>>>> 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+).
>>>>
>>>
>>> "For users to have the ability to inspect and control the
>>> settings, each application also needs to:
>>>
>>>    o  provide configuration options to manually override the default
>>> settings so that resolution is performed via
>>> 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."
>>>
>>
>> - 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).
>
> 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.

---

From: Vittorio Bertola <[email-masked]>
Date: Tue, 7 Apr 2020 17:40:51 +0200 (CEST)

>     Il 07/04/2020 17:23 Eric Rescorla <[email-masked]> ha scritto:
> 
> 
> 
>     On Tue, Apr 7, 2020 at 7:38 AM Sara Dickinson < [email-masked] mailto:[email-masked] > wrote:
> 
>     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.."
> 
I don't understand where in the proposed text there was a reference to malware that prompted further discussion of the effectiveness of using DNS to counter it. In any case, if we think that we need to discuss this topic at that point in the draft, one should also note that there also are ways to prevent malware from reaching a different resolver, though they are less likely to work once connections are encrypted, etc. But I think that this would make reaching consensus even harder, so perhaps we could avoid doing so and just focus on suggestions related to application configuration.

--

Vittorio Bertola | Head of Policy & Innovation, Open-Xchange
[email-masked] mailto:[email-masked] 
Office @ Via Treviso 12, 10144 Torino, Italy

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 7 Apr 2020 08:47:57 -0700

On Tue, Apr 7, 2020 at 8:40 AM Vittorio Bertola <
[email-masked]> wrote:

> On Tue, Apr 7, 2020 at 7:38 AM Sara Dickinson < [email-masked]> wrote:
>
> 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.."
>
> I don't understand where in the proposed text there was a reference to
> malware that prompted further discussion of the effectiveness of using DNS
> to counter it. In any case, if we think that we need to discuss this topic
> at that point in the draft, one should also note that there also are ways
> to prevent malware from reaching a different resolver, though they are less
> likely to work once connections are encrypted, etc. But I think that this
> would make reaching consensus even harder, so perhaps we could avoid doing
> so and just focus on suggestions related to application configuration.
>

Well, I would be happy to strike this text entirely. However, the text
speaks of "control" and if we're going to say that, we should acknowledge
that the system DNS is not going to let you control malicious applications
because malware can just do its own resolution. As it is, I think the text
gives a false impression

-Ekr

-- 
> [email-masked]

---

From: Eric Orth <[email-masked]>
Date: Tue, 7 Apr 2020 12:11:05 -0400

It is currently a very common* misunderstanding that system or
browser/application DNS configuration can somehow control malware
resolution.  Common enough that, IMO, any text on how to "control" or
configure resolution or "disable" features like DoH should include at least
a small clarification on the point of the scope/limitations of that
configuration.

*Anecdotal evidence is the large number of times I have been asked for
guidance on "stopping malware" through disabling Chrome DoH.  I always have
to give the reminder that I can only help with controlling resolutions
which go through Chrome, which malware will often not do.

---

From: Sara Dickinson <[email-masked]>
Date: Tue, 7 Apr 2020 17:12:47 +0100

> On 7 Apr 2020, at 16:47, Eric Rescorla <[email-masked]> wrote:
> 
> 
> 
> On Tue, Apr 7, 2020 at 8:40 AM Vittorio Bertola <[email-masked] <mailto:[email-masked]>> wrote:
> 
>> Il 07/04/2020 17:23 Eric Rescorla <[email-masked] <mailto:[email-masked]>> ha scritto:
>> 
>> 
>> 
>> On Tue, Apr 7, 2020 at 7:38 AM Sara Dickinson < [email-masked] <mailto:[email-masked]>> wrote: 
> Well, I would be happy to strike this text entirely. However, the text speaks of "control" and if we're going to say that, we should acknowledge that the system DNS is not going to let you control malicious applications because malware can just do its own resolution. As it is, I think the text gives a false impression 

How about making the last sentence a little more specific instead:

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 the DNS queries generated by such applications, or manage them to set consistent application-level controls across the device for e.g. domain based query re-direction or filtering. “

Sara. 

> [email-masked] <mailto:[email-masked]>

---

From: Eric Orth <[email-masked]>
Date: Tue, 7 Apr 2020 12:22:49 -0400

"consistent application-level controls across the device"

Right there is where followers of the misunderstanding will read this text
incorrectly.  Browsers and other non-malicious applications allowing
control does not guarantee consistent application control.

On Tue, Apr 7, 2020 at 12:13 PM Sara Dickinson <[email-masked]> wrote:

> 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 the
> DNS queries generated by such applications, or manage them to set
> consistent application-level controls across the device for e.g. domain
> based query re-direction or filtering. “
>
> Sara.
>
>
> -Ekr
>
> --
>>
> _______________________________________________
> dns-privacy mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dns-privacy
>

---

From: Sara Dickinson <[email-masked]>
Date: Thu, 9 Apr 2020 12:00:11 +0100

> On 7 Apr 2020, at 17:22, Eric Orth <[email-masked]> wrote:
> 
> Right there is where followers of the misunderstanding will read this text incorrectly.  Browsers and other non-malicious applications allowing control does not guarantee consistent application control.
> 
> On Tue, Apr 7, 2020 at 12:13 PM Sara Dickinson <[email-masked] <mailto:[email-masked]>> wrote:
> 
> 
>> On 7 Apr 2020, at 16:47, Eric Rescorla <[email-masked] <mailto:[email-masked]>> wrote:
>> 
>> 
>> 

If the feeling is that it is really needed then I would suggest text that is consistent with that used in section 3.5.2.1, for example:

“ In addition, if a client device is compromised by a malicious application, the attacker can
  use application-specific DNS resolvers, transport and settings of its own choosing.”

Sara. 

> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/dns-privacy <https://www.ietf.org/mailman/listinfo/dns-privacy>

---

From: Vittorio Bertola <[email-masked]>
Date: Thu, 9 Apr 2020 14:20:53 +0200 (CEST)

>     Il 07/04/2020 18:22 Eric Orth <[email-masked]> ha scritto:
> 
> 
Thanks, now I get the point. But it is in line with Sara's text, which starts with an "if": "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." (I have no problems in replacing the movement verb "revert" with a static one). Of course DNS-based malware won't provide that setting, and it's fine to add a warning to the user that not all the applications will comply with the best practice that we are suggesting, though it's also implicit in the concept of a best practice.

The point that I'd like to have in the text is that it would be good if at least the well-intentioned applications empowered their users, so that those few smarter ones that really want to pick their resolver have a simple way to do so. Ideally, the OS would have a way to signal to all applications that the user explicitly wants a specific resolver, rather than whatever default is suggested by the application and/or by the network, so that applications pick up that preference without even requiring the user to manually configure each of them; the preference could even be for a deployment/discovery model rather than for a single specific resolver. Anyway, I'm fine with Sara's latest text proposals.

--

---

From: Eric Rescorla <[email-masked]>
Date: Thu, 9 Apr 2020 06:24:21 -0700

On Thu, Apr 9, 2020 at 4:00 AM Sara Dickinson <[email-masked]> wrote:

> If the feeling is that it is really needed then I would suggest text that
> is consistent with that used in section 3.5.2.1, for example:
>

Sort of. This seems like it still buries the lede.

"Note that if a client device is compromised by a malicious application,
the attacker can use application-specific DNS resolvers, transport and
settings of its own choosing and thus will not be affected by these
controls."

---

From: Sara Dickinson <[email-masked]>
Date: Thu, 9 Apr 2020 14:36:21 +0100

> On 9 Apr 2020, at 14:24, Eric Rescorla <[email-masked]> wrote:
> 

<snip>

> "Note that if a client device is compromised by a malicious application, the attacker can use application-specific DNS resolvers, transport and settings of its own choosing and thus will not be affected by these controls.”

By 'these controls’ do you mean any controls that the malicious application appears to offer to the user? If so, then does this capture your point: 

"Note that if a client device is compromised by a malicious application, the attacker can use application-specific DNS resolvers, transport and settings of its own choosing regardless of what DNS configuration the malicious application may appear to offer the user (if any).”

Sara.

---

From: Eric Rescorla <[email-masked]>
Date: Thu, 9 Apr 2020 07:35:02 -0700

On Thu, Apr 9, 2020 at 6:36 AM Sara Dickinson <[email-masked]> wrote:

> controls.”
> By 'these controls’ do you mean any controls that the malicious
> application appears to offer to the user? If so, then does this capture
> your point:
>
> settings of its own choosing regardless of what DNS configuration the
> malicious application may appear to offer the user (if any).”
>

No. My point is that the platform level DNS controls that you are trying to
use don't work in this case.

-Ekr

---

From: Sara Dickinson <[email-masked]>
Date: Mon, 20 Apr 2020 11:41:26 +0100

> On 9 Apr 2020, at 15:35, Eric Rescorla <[email-masked]> wrote:
> 
> 
> 
> On Thu, Apr 9, 2020 at 6:36 AM Sara Dickinson <[email-masked] <mailto:[email-masked]>> wrote:
> 
> 
>> On 9 Apr 2020, at 14:24, Eric Rescorla <[email-masked] <mailto:[email-masked]>> wrote:
>> 
> 
> <snip>
> 
>>> 
> No. My point is that the platform level DNS controls that you are trying to use don't work in this case.

I see the confusion now, the sentence beginning ‘If not,’ was meant to refer to whether (if they didn’t support using the system resolver) individual applications offered per-application settings to inspect/manage the DNS queries e.g. export session keys. To try to rework the text in context:

"An increasing number of applications are offering application-specific encrypted DNS resolution settings, rather than defaulting to using only the system resolver.  A variety of heuristics and resolvers are available in different applications including hard-coded lists of recognized DoH/DoT servers.

For users to have the ability to manage the DNS resolver settings for each individual application in a similar fashion to the OS DNS settings, each application would need to expose the default settings to the user, provide a configuration interface to change them, and support configuration of user specified resolvers.  

The system resolver resolution path is sometimes used to configure additional DNS controls e.g. query logging, domain based query re-direction or filtering. 
If all of the applications used on a given device can be configured to use the system resolver, such controls need only be configured on the system resolver resolution path. However if applications offer neither the option to use the system resolver nor equivalent application-specific DNS controls then users should take note that for queries generated by such an application they may not be able to
* directly inspect the DNS queries (e.g. if they are encrypted), or 
* manage them to set DNS controls across the device which are consistent with the system resolver controls. 

Note that if a client device is compromised by a malicious application, the attacker can use application-specific DNS resolvers, transport and controls of its own choosing.“

Sara.

---

From: Sara Dickinson <[email-masked]>
Date: Tue, 28 Apr 2020 14:51:22 +0100

Hi Ekr, 

Could you comment on the latest proposed text below? I believe this is the last comment to resolve from the IETF LC on this draft...

Best regards

Sara. 

> On 20 Apr 2020, at 11:41, Sara Dickinson <[email-masked]> wrote:
> 
> 
> 
>> On 9 Apr 2020, at 15:35, Eric Rescorla <[email-masked] <mailto:[email-masked]>> wrote:
>> 
>> 
>>