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

[Sara Dickinson <[e-mail]>]

> On 11 May 2020, at 13:56, Eric Rescorla <[e-mail]> wrote:
> 
> 
> 
> On Mon, May 11, 2020 at 5:34 AM Sara Dickinson <[e-mail] <mailto:[e-mail]>> wrote:
> 
> 
> > On 7 May 2020, at 17:41, Eric Rescorla <[e-mail] <mailto:[e-mail]>> 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. 

Suggest modify the text about the OS settings to:

“ All major OS's expose the system DNS settings and allow users to manually override them if desired (on some systems this might be limited to only those users who have administrator rights.)”

And update the first and second paragraphs of this section to the following:

“An increasing number of applications are offering application-specific DNS resolution settings, rather than
defaulting to using only the system resolver. It should be noted that the privileges required to install such an application vary and so it may be possible to bypass administrator level controls on OS DNS resolver settings via this route. Many such applications offer encrypted transports - for these applications a variety of heuristics and resolvers are available including hard-coded lists of recognized DoH/DoT servers."

In order for users that are able to update their OS DNS resolver settings to have the ability to manage the DNS resolver settings for
each individual application in a similar fashion, 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.
> > 
> > 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.

Above text changes should address this problem…? 

Sara.