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 protected]> wrote: > > > >> On 9 Apr 2020, at 15:35, Eric Rescorla <[email protected] >> <mailto:[email protected]>> wrote: >> >> >> >> On Thu, Apr 9, 2020 at 6:36 AM Sara Dickinson <[email protected] >> <mailto:[email protected]>> wrote: >> >> >>> On 9 Apr 2020, at 14:24, Eric Rescorla <[email protected] >>> <mailto:[email protected]>> 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. >
_______________________________________________ dns-privacy mailing list [email protected] https://www.ietf.org/mailman/listinfo/dns-privacy
