> On 7 Apr 2020, at 17:22, Eric Orth <[email protected]> wrote:
> 
> "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 protected] 
> <mailto:[email protected]>> wrote:
> 
> 
>> On 7 Apr 2020, at 16:47, Eric Rescorla <[email protected] 
>> <mailto:[email protected]>> wrote:
>> 
>> 
>> 
>> On Tue, Apr 7, 2020 at 8:40 AM Vittorio Bertola 
>> <[email protected] 
>> <mailto:[email protected]>> wrote:
>> 
>>> Il 07/04/2020 17:23 Eric Rescorla <[email protected] <mailto:[email protected]>> ha 
>>> scritto:
>>> 
>>> 
>>> 
>>> On Tue, Apr 7, 2020 at 7:38 AM Sara Dickinson < [email protected] 
>>> <mailto:[email protected]>> wrote: 
>>> 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.."
>> 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 
> 
> 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.”

Sara. 


> 
> Sara. 
> 
>> 
>> -Ekr
>> 
>> -- 
>> 
>> Vittorio Bertola | Head of Policy & Innovation, Open-Xchange
>> [email protected] <mailto:[email protected]> 
>> Office @ Via Treviso 12, 10144 Torino, Italy
> 
> _______________________________________________
> dns-privacy mailing list
> [email protected] <mailto:[email protected]>
> https://www.ietf.org/mailman/listinfo/dns-privacy 
> <https://www.ietf.org/mailman/listinfo/dns-privacy>

_______________________________________________
dns-privacy mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dns-privacy

Reply via email to