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

[Sara Dickinson <[e-mail]>]

> On 3 Mar 2020, at 11:34, Vittorio Bertola <[e-mail]> wrote:
> 
> 
>> Il 02/03/2020 16:16 Sara Dickinson <[e-mail]> ha scritto:
>> 
>> 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."
> I don't want to nitpick, but I'd point out that from the policy/privacy viewpoint what is important is which resolver is used, not (as long as it does not add any specific new privacy risk) the interface used to contact it - so the second and third "*" bullets are functionally equivalent and it would be fine if an application provided only either one of the two. 

You are broadly correct,  but there are some small differences in that for the second bullet point not all applications may offer the preferred transport (e.g. most browsers don’t support DoT but my preferred resolver might only support DoT) or config options e.g. to omit the User-agent HTTP header. It will also mean X different applications making X different connections to the resolver (which could reveal the set of applications the user has installed). Whereas if everything goes through the system resolver the device appears to the resolver as a single source of queries using a set of connections managed only from the system resolver. 

> 
> In theory, one could say that the two interfaces are not completely privacy-equivalent, since the use of the system API introduces one more party that gets access to data, i.e. the operating system - so one could argue that applications should bypass the OS to prevent it from spying over the user's DNS traffic, exactly like they do with the network. If this is what we want to argue, then we should remove the last "*" bullet. However, exactly as the network, the OS might want to exert some general policy over the user's DNS traffic, such as monitoring infections or filtering specific destinations, so I don't know if such a recommendation would be beneficial in the end. 


This is an interesting point! Note that a user may want to use the system resolver as a point to monitor their own traffic. For example, having multiple sources of DNS queries doesn’t necessarily provide the same ability to troubleshoot issues as a single component does, or (more importantly) to inspect the encrypted traffic leaving the machine. Firefox nicely allows users to export session keys so the traffic can be decrypted locally (and also provides an interface to look at the DNS results), but if an application doesn’t offer this then the user may have no ability to easily see their own DNS traffic. I’ve thought in the past of proposing this as an additional option for the applications (and in future on any OS that implements an encrypted transport) but didn’t follow up.

Sara.