> On 7 May 2020, at 17:41, Eric Rescorla <[email protected]> wrote: > > Extensively trimming: > > To be honest, this thread has gotten so long that I've lost > track of the various changes being proposed, so here's > my comments on the text as a whole. >
To be honest, I really thought we had pretty much converged on some text that had consensus for this section... > > > > "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. > > As I said earlier, I think this text is highly misleading. > There are at least two major loci of filtering via DNS: > > 1. In the operating system itself via the system resolver > or hooks into that resolver. > > 2. In the network via (a) the selected resolver or (b) on-path > filtering of the traffic to/from that resolver. > > There are least three major application resolution technologies that > render one or more of these techniques ineffective: > > 1. Using an application-level resolver which uses the system settings > [what Chrome currently does] bypasses (1) > > 2. Using an application-level resolver which uses DoH/DoT to the > system configured resolver [what Edge and Chrome are experimenting > with] bypasses (1) and maybe 2(b) if the network config gets out of > sync (i.e., you don't want your system configured resolver to do > DoH/DoT if you use network-level filtering, but it's easy to see > how this can happen if (for instance) you just offer the the user > the ISP resolver and they start supporting DoH/DoT > > 3. Using an application-level resolver which uses DoH/DoT to > an application-selected resolver [as in the Firefox TRR > system] bypasses all of these. > > The key point is that a lot of filtering is broken by reasons > that have nothing to do with encrypted transport, and so > this text is misleading. Somewhat confused here.. the text you quote above does not mention filtering at all, was added in version -04 published in January and wasn’t referenced at all in your first review of -04. Are you now saying you want this specific text reworked? > > > > 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. > > This seems sort of true, though of course in some systems (I don't > know how common this is in the world of mostly single-user computers) > users actually can't change the system resolver settings. We previously agreed text in section 6.1.1 that says both: “ All major OS's expose the system DNS settings and allow users to manually override them if desired." “The vast majority of users do not change their default system DNS settings and so implicitly accept the network settings for DNS." Getting into user specific authorisations around this isn’t something that has been proposed in any comment before and I’m not sure how useful it is at this point? > > > > The system resolver resolution path is sometimes used to configure > > additional DNS controls e.g. query logging, domain based query > > re-direction or filtering. > > This conflates the network and in-OS filtering discussed above, > which I really think needs expansion. Suggest: “The system resolver resolution path is sometimes used to configure additional device based DNS controls (distinct from any controls implemented at the network level) e.g. local 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. > > OK. > > > > 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. » > > This seems opaque. Why not say "then any DNS-based controls may be > ineffective.” Will add that at the end of the sentence - this text was trying to be consistent with the similar text you earlier proposed for the similar case in section 6.2.1. “ In addition, if the client is compromised, the attacker can replace the DNS configuration with one of its own choosing." Sara. _______________________________________________ dns-privacy mailing list [email protected] https://www.ietf.org/mailman/listinfo/dns-privacy
