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

[Sara Dickinson <[e-mail]>]

> On 9 Apr 2020, at 15:35, Eric Rescorla <[e-mail]> wrote:
> 
> 
> 
> On Thu, Apr 9, 2020 at 6:36 AM Sara Dickinson <[e-mail] <mailto:[e-mail]>> wrote:
> 
> 
>> On 9 Apr 2020, at 14:24, Eric Rescorla <[e-mail] <mailto:[e-mail]>> wrote:
>> 
> 
> <snip>
> 
>>> 
>>> 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. “
>> 
>> 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.”
>> 
>> 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.”
> 
> 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).”
> 
> 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. 

> 
> -Ekr
> 
> 
> Sara.