On Mon, May 11, 2020 at 5:34 AM Sara Dickinson <[email protected]> wrote:
> > > > 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... > As I said at the beginning, i think it's generally problematic, for the reasons below, but as you insist on keeping it, I'm giving it a close read, and in that context, this framing is problematic. > > > "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? > The problem isn't this text specifically, it's that it's used in context for a section talking about how DoH and DoT interfere with filtering, but, as detailed above, that's only part of the story. > > > 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." > Yes, this is true as well. > > “The vast majority of users do not change their default system DNS > settings and so implicitly accept the network settings for DNS." > Yes, I think this is true. 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? > Well, the issue is that this text is being used to contrast application-specific settings to OS ones, so I'm not sure how not to get into it. > > > 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." > Well, I agree with this parenthetical, but then it just reinforces my point that this not being about *encrypted* DNS but rather about application-specific DNS, because this text then becomes about method (1) and therefore implicates any application-level resolver, encrypted or not. > > > > > > > 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." > Sure, I'm fine with my phrasing as well, but trying to expand it out as you have (especially by adding 'controls') is confusing. -Ekr > Sara. > > >
_______________________________________________ dns-privacy mailing list [email protected] https://www.ietf.org/mailman/listinfo/dns-privacy
