Re: [dns-privacy] Datatracker State Update Notice:

[Christian Huitema]

On 5/11/2020 7:27 AM, Sara Dickinson wrote:
>> 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."


This discussion pushed me to review draft-ietf-dprive-rfc7626-bis-05. I
do like the general structure of the document, but I have two
observations -- a minor one first regarding recursive resolvers on the
end device, and a big sticking point with the discussion of resolvers
embedded in an application.

The paragraph in section 5.1 seems to imply that embedding a recursive
resolver in the end point or close to reduces the privacy attack surface:

   o  The recursive resolver can be on the end user's device.  In
  (currently) a small number of cases, individuals may choose to
  operate their own DNS resolver on their local machine.  In this
  case, the attack surface for the connection between the stub
  resolver and the caching resolver is limited to that single
  machine.

That's a very debatable statement. In the absence of encryption, the
only practical reduction in observable traffic is the amount of caching
performed in the device's resolver, and a caching stub resolver would
get similar reduction. In the presence of encryption, the multiple
connections between the local resolver and the authoritative servers
expose more data than encrypted traffic between stub and resolver. The
local recursive resolver will not expose data to a third party recursive
resolver, but it will expose data to authoritative resolvers, as
explained in section 6.2. At a minimum, I would like to see a forward
pointer to section 6.2 in the recursive resolver on device paragraph. A
general warning that this is a trade-off would be nice too.

I found the discussion of application embedded resolvers bizarre. It
speaks of applications in general, but the way the text is set-up
appears to be a specific dig against Mozilla. Look at the text: "popular
applications directing DNS traffic by default to specific dominant
resolvers". It boils down to accusing some unnamed application of
deliberately contributing to centralization. I find that problematic,
and also very imprecise. I think this should be rewritten in a much more
neutral way.

In a modern environment, the concept of host is very fuzzy. We get all
kinds of special devices. We also get containers or virtual machines
running inside hosts. A browser is in practice such a container. There
is not a difference of nature between a separate subsystem like a
browser environment and a separate device. If a browser embeds its own
stub resolver, users can configure the resolver of their choice in much
the same way that they can configure the resolver of their choice using
a device configuration UI. There are differences in management, but
these differences fall largely outside the scope of the DNS privacy draft.

In both cases, users are very likely to configure a well-known service.
There is not much the difference between setting the device's preferred
resolver to 8.8.8.8 and setting the browser's choice to "Google DNS"? In
both cases, the centralization effect results from the popularity of the
service, unless you are specifically accusing Mozilla of conspiring to
centralize the DNS. And a privacy RFC is not the right place to do that.

I would like to see the "popular applications" sentence rewritten in a
much more neutral way. Maybe something like:

* applications that embed their own stub resolvers and allow
configuration of the DNS resolver independently of system defaults.

And leave it at that. No innuendo, no allegations of hidden motives.

As for section 6.1.1.2, I would scratch most of it, maybe just keeping
the very 

Re: [dns-privacy] Datatracker State Update Notice:

[Sara Dickinson]

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

Re: [dns-privacy] Datatracker State Update Notice:

[Eric Rescorla]

On Mon, May 11, 2020 at 5:34 AM Sara Dickinson  wrote:

>
>
> > On 7 May 2020, at 17:41, Eric Rescorla  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 

Re: [dns-privacy] Datatracker State Update Notice:

[Sara Dickinson]

> On 7 May 2020, at 17:41, Eric Rescorla  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