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

From: "Eric Vyncke (evyncke)" <[email-masked]>
Date: Tue, 5 May 2020 09:10:30 +0000

Eric / Ekr,

Sara has posted a revised I-D, does it address the point in your email dated 9th of April ?

She also replied end of April with:

“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. »

Thank you for your prompt reply

-éric V (the other one)

From: Eric Rescorla <[email-masked]>
Date: Thursday, 9 April 2020 at 16:35
To: Sara Dickinson <[email-masked]>
Cc: Eric Orth <[email-masked]>, "[email-masked]" <[email-masked]>, Vittorio Bertola <[email-masked]>, "[email-masked]" <[email-masked]>, Eric Vyncke <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [dns-privacy] Datatracker State Update Notice: <draft-ietf-dprive-rfc7626-bis-04.txt>

On Thu, Apr 9, 2020 at 6:36 AM Sara Dickinson <[email-masked]<mailto:[email-masked]>> wrote:

On 9 Apr 2020, at 14:24, Eric Rescorla <[email-masked]<mailto:[email-masked]>> 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.

-Ekr

Sara.

---

From: Eric Rescorla <[email-masked]>
Date: Thu, 7 May 2020 09:41:34 -0700

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.

> "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.

> 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.

> 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.

> 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
>
> * 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."

-Ekr

---

From: Sara Dickinson <[email-masked]>
Date: Mon, 11 May 2020 13:34:33 +0100

> On 7 May 2020, at 17:41, Eric Rescorla <[email-masked]> wrote:
> 
> Extensively trimming:
> 

To be honest, I really thought we had pretty much converged on some text that had consensus for this section...

> that have nothing to do with encrypted transport, and so

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?

> 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?

> 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."

> 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.

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 11 May 2020 05:56:04 -0700

> 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.

> 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.

>    manually override them if desired."

Yes, this is true as well.

>    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 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.

> 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

---

From: Sara Dickinson <[email-masked]>
Date: Mon, 11 May 2020 15:27:04 +0100

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

> 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.

---

From: Christian Huitema <[email-masked]>
Date: Mon, 11 May 2020 12:35:11 -0700

On 5/11/2020 7:27 AM, Sara Dickinson wrote:
>> application-specific settings to OS ones, so I'm not sure how not to
>> get into it. 
>
> “ 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.)”
>
> “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

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 first and the very last paragraph. The text in between does not
add much to the specific topic of DNS privacy. Also, there is the ADD
working group dedicated to discovery and configuration of encrypted
servers. There is no point in anticipating their results.

-- Christian Huitema

---

From: Vittorio Bertola <[email-masked]>
Date: Tue, 12 May 2020 14:14:43 +0200 (CEST)

>     Il 11/05/2020 21:35 Christian Huitema <[email-masked]> ha scritto:
> 
> 
>     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.
> 
I think this section has already been rewritten at least half a dozen times, and every time there was a claim that it is not neutral (sometimes even on text that previously seemed to be ok). Every time the authors put the effort to rewrite it once again according to the comment, and every time a new comment comes in saying that this is not enough. I admire their patience.

In any case, I don't know Mozilla's view on whether this is a specific dig against them, but it is meant as a discussion on privacy impacts of a specific deployment model, not of a specific company's policy. These privacy impacts, even if with very variable views, have been the subject of many conferences, articles and talks in the last couple of years - they were not discovered in this document, and it would be weird if they were omitted from a discussion on DNS privacy released in 2020. The fact that Mozilla is at this time the only company adopting that model is just coincidental, apart from perhaps reflecting the fact that others think that that model is not a particularly good idea.

> 
>     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.
> 
You seem to miss the point, which is not about users setting their preferred resolver at the application level, but about applications that by default ignore the resolver settings in the device and pick their own preferred resolver independently from the user.

In a market in which there are few choices, indeed this behaviour promotes centralization: we know that most users do not change the defaults, and if most users of a popular application start using a single resolver in place of a broad set of local resolvers scattered around the Internet, of course the resulting traffic pattern is more centralized.

We also know that centralization of the DNS is potentially a privacy threat, as it makes it easier to track and correlate multiple activities by the same individual. This does not seem contentious - it was actually the first example in last year's IAB "DEDR" workshop charter.

Moreover, this potential downside for privacy can be entirely countered by increased privacy protections offered by the new operator, and this is clearly stated in the final paragraph.

The central paragraphs were initially meant to say that, to preserve the user's privacy, the user should always be given controls to set the resolver. This is in line with the basic principle of most privacy-protecting policy frameworks, i.e. user consent.

However, the current text just says that "if" we wanted to give users the same degree of control they currently have in basically any consumer-oriented operating system, then applications should provide users with controls (any control goes, even if hidden under a 3-click-deep configuration hierarchy, as you have to do today if you really want to reject advertising cookies on the average commercial website). Then, the text adds that if applications don't do it, users might not... be able to control their resolver.

There is not even any more a stance that says that users should be able to choose where their DNS queries go, or that the lack of such choice is in itself a privacy problem. From the perspective of a privacy advocate, this section is now quite watered down.

I am also puzzled by the fact that this draft was actually in last call six months ago, and it only received a single objection just before the deadline, and since then we have entered an endless cycle changing it again and again and again. I did my best to help with compromise text as requested but I do not understand where this process is going.

--

Vittorio Bertola | Head of Policy & Innovation, Open-Xchange
[email-masked] mailto:[email-masked] 
Office @ Via Treviso 12, 10144 Torino, Italy

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Tue, 12 May 2020 17:18:05 +0200

On Tue, May 12, 2020 at 02:14:43PM +0200,
 Vittorio Bertola <[email-masked]> wrote 
 a message of 144 lines which said:

> Every time the authors put the effort to rewrite it once again
> according to the comment, and every time a new comment comes in
> saying that this is not enough. I admire their patience.

Not "the authors", just Sara, she was the one patient and
hard-working, the other author was lazy.

> I think this section has already been rewritten at least half a
> dozen times, and every time there was a claim that it is not neutral
> (sometimes even on text that previously seemed to be ok).

Yes, and I think I know now the root of the problem. 7626bis tries to
go too far and, instead of discussing the DNS protocol and its privacy
issues, now goes into end hosts and discuss what is done inside the
machine, and what should be done. This is certainy interesting, and it
certainly has consequences on privacy, user control, etc but:

1) It is a bit outside IETF's domain, since it is not inside the
network,
2) There is clearly no consensus inside IETF about it.

My personal opinion is now that the best way out of the problem is to
drop discussions about internal (to the end host) issues.

> These privacy impacts, even if with very variable views, have been
> the subject of many conferences, articles and talks in the last
> couple of years

Which clearly demonstrated that there is no consensus about it.

> You seem to miss the point, which is not about users setting their
> preferred resolver at the application level, but about applications
> that by default ignore the resolver settings in the device and pick
> their own preferred resolver independently from the user.

There is zero difference between an user using the resolver configured
in the OS and the user using the resolver configured in the
application. In both cases, the user uses the default value, not
knowing how to change it or if he/she should change it, or even that
it exists.

Also, Christian is right here: there is no clear definition of OS
vs. application and creating one seems to me quite outside of IETF's
realm.

> I am also puzzled by the fact that this draft was actually in last
> call six months ago, and it only received a single objection just
> before the deadline, and since then we have entered an endless cycle
> changing it again and again and again. I did my best to help with
> compromise text as requested but I do not understand where this
> process is going.

See my suggestion: IETF should stop discussing relationship between OS
and apps (which is fuzzy, anyway) and should focus on network
protocols.

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Tue, 12 May 2020 17:33:45 +0200

On Mon, May 11, 2020 at 12:35:11PM -0700,
 Christian Huitema <[email-masked]> wrote 
 a message of 294 lines which said:

> 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:

Note that it was already in RFC 7626 (which does not mean it was
right). I agree with you that there is a weakness in the reasoning (a
sniffer located between such a resolver and the rest of the Internet
would see a lot since a one-user resolver may have little caching).

I think the problem is that the RFC (in 7626-ter?) should better
separate upstream surveillance (before the resolver), downstream
surveillance (after the resolver) and internal surveillance (inside
the resolver). Using a in-host resolver decreases upstream
surveillance and suppresses internal surveillance, but does little for
downstream surveillance (because of limited caching). Using a remote
resolver with DoT or DoH to reach it may expose to internal
surveillance (if the trust in this resolver is misplaced) but
decreases upstream and downstream (because of caching) surveillance.

> 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 agree and I suggest "As it is often the case with privacy, there is
a trade-off here. A local (to the user's machine or LAN) resolver
reduces the risk that the resolver's administrator read the user's DNS
traffic, but it does not protect a lot against later sniffing, done at
the place where the resolver talks with authoritative name servers."

> I found the discussion of application embedded resolvers bizarre.

See <https://mailarchive.ietf.org/arch/msg/dns-privacy/ZATyqXQ6ccNHTqsMpbq__3a72WM>
I know think that it is indeed on the wrong track.

> running inside hosts. A browser is in practice such a container.

I agree that OSvsApplication it should not be in this draft.

> As for section 6.1.1.2, I would scratch most of it,

I completely agree.

---

From: Ben Schwartz <[email-masked]>
Date: Tue, 12 May 2020 23:12:35 -0400

On Tue, May 12, 2020 at 8:15 AM Vittorio Bertola <vittorio.bertola=
[email-masked]> wrote:

> 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
> deliberately contributing to centralization. I find that problematic, and
> also very imprecise. I think this should be rewritten in a much more
> neutral way.
>
> I think this section has already been rewritten at least half a dozen
> times, and every time there was a claim that it is not neutral (sometimes
> even on text that previously seemed to be ok). Every time the authors put
> the effort to rewrite it once again according to the comment, and every
> time a new comment comes in saying that this is not enough. I admire their
> patience.
>
> In any case, I don't know Mozilla's view on whether this is a specific dig
> against them, but it is meant as a discussion on privacy impacts of a
> specific deployment model, not of a specific company's policy. These
> privacy impacts, even if with very variable views, have been the subject of
> many conferences, articles and talks in the last couple of years - they
> were not discovered in this document, and it would be weird if they were
> omitted from a discussion on DNS privacy released in 2020. The fact that
> Mozilla is at this time the only company adopting that model is just
> coincidental, apart from perhaps reflecting the fact that others think that
> that model is not a particularly good idea.
>
> 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.
>
> preferred resolver at the application level, but about applications that by
> default ignore the resolver settings in the device and pick their own
> preferred resolver independently from the user.
>
> In a market in which there are few choices, indeed this behaviour promotes
> centralization: we know that most users do not change the defaults, and if
> most users of a popular application start using a single resolver in place
> of a broad set of local resolvers scattered around the Internet, of course
> the resulting traffic pattern is more centralized.
>
> We also know that centralization of the DNS is potentially a privacy
> threat, as it makes it easier to track and correlate multiple activities by
> the same individual. This does not seem contentious - it was actually the
> first example in last year's IAB "DEDR" workshop charter.
>

That seems quite contentious to me.  Decentralization of the DNS is _also_
a privacy threat: running your own recursive leaks your IP to every
authoritative (far worse than ECS!), pinning yourself to a unique recursive
makes you uniquely identifiable as you move across the network, and using a
recursive whose identity is unknown is obviously a privacy concern.

There are many possible resolution configurations, and none of them offer
perfect privacy.  The exact tradeoffs between them are very much in flux as
the relevant standards and practices evolve.  If the draft tries to cover
this topic it should present all of the risks in these different
configurations, but I think it would probably be wiser to avoid claims
about the privacy properties of deployment architectures.

Moreover, this potential downside for privacy can be entirely countered by
> increased privacy protections offered by the new operator, and this is
> clearly stated in the final paragraph.
>
> The central paragraphs were initially meant to say that, to preserve the
> user's privacy, the user should always be given controls to set the
> resolver. This is in line with the basic principle of most
> privacy-protecting policy frameworks, i.e. user consent.
>
> However, the current text just says that "if" we wanted to give users the
> same degree of control they currently have in basically any
> consumer-oriented operating system, then applications should provide users
> with controls (any control goes, even if hidden under a 3-click-deep
> configuration hierarchy, as you have to do today if you really want to
> reject advertising cookies on the average commercial website). Then, the
> text adds that if applications don't do it, users might not... be able to
> control their resolver.
>
> There is not even any more a stance that says that users should be able to
> choose where their DNS queries go, or that the lack of such choice is in
> itself a privacy problem. From the perspective of a privacy advocate, this
> section is now quite watered down.
>
> I am also puzzled by the fact that this draft was actually in last call
> six months ago, and it only received a single objection just before the
> deadline, and since then we have entered an endless cycle changing it again
> and again and again. I did my best to help with compromise text as
> requested but I do not understand where this process is going.
>
> --
>
> [email-masked]
> _______________________________________________
> dns-privacy mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dns-privacy
>

---

From: Vittorio Bertola <[email-masked]>
Date: Wed, 13 May 2020 11:42:59 +0200 (CEST)

>     Il 13/05/2020 05:12 Ben Schwartz <bemasc=[email-masked]> ha scritto:
> 
> 
> 
> 
>     On Tue, May 12, 2020 at 8:15 AM Vittorio Bertola <vittorio.bertola= [email-masked] mailto:[email-masked] > wrote:
> 
>     That seems quite contentious to me.  Decentralization of the DNS is _also_ a privacy threat: running your own recursive leaks your IP to every authoritative (far worse than ECS!), pinning yourself to a unique recursive makes you uniquely identifiable as you move across the network, and using a recursive whose identity is unknown is obviously a privacy concern.
> 
I agree with that, but the two statements are not incompatible with each other. Also, I will note that you are comparing oranges with apples: "centralization of the DNS", as used above, is not about replacing your own recursive with a third party one, but about replacing in the overall DNS resolution system many independent third party resolvers with a single third party resolver that serves many more users. So "decentralization of the DNS" would mean promoting the existence of a higher number of independent resolvers and letting users pick easily and safely the one(s) they want to use, and in that sense it would clearly reduce mass surveillance opportunities, at least until you get to a situation in which each resolver has so few users that it can be used to identify them (which is not a common situation for the average Internet user).

--

---

From: Vittorio Bertola <[email-masked]>
Date: Wed, 13 May 2020 12:27:22 +0200 (CEST)

> Il 12/05/2020 17:18 Stephane Bortzmeyer <[email-masked]> ha scritto:
> 

I disagree. There are IETF documents that provide policy-level analysis of complex technical issues and do so throughout the entire network architecture, both in terms of layers and in terms of hosts. For example, RFC 7754 has an entire section devoted to what happens within the endpoints and within applications that run on them.

Also, RFC 6973, which is the document that this draft tries to apply, has an entire section of the guidelines (7.2) that instructs to discuss issues of user control, which is what 6.1.1.2 deals with. Actually, the first point of the section is:

      "What controls or consent mechanisms does the
       protocol define or require before personal data or identifiers
       are shared or exposed via the protocol?  If no such mechanisms or
       controls are specified, is it expected that control and consent
       will be handled outside of the protocol?"

There even is an explicit reference to discussing how control and consent is handled outside of the protocol.

> 2) There is clearly no consensus inside IETF about it.

This is a different matter. However, there is also no consensus on dropping this part - certainly I would not agree. It does not make sense to have a "DNS Privacy Considerations" document that ignores parts of the problem. These issues are so interlinked that there is no clear single "more privacy" switch. Each of the technical solutions, both within the protocol and within its clients, could provide more or less privacy depending on a number of other considerations, some of which are not about technical protocol design but are nonetheless relevant. Either you analyze them in full, or the analysis is going to be incorrect and misleading.

> drop discussions about internal (to the end host) issues.

Again, I disagree. The solution is to find reasonable compromise text that can be acceptable for all while not making anyone really happy. What was in the last draft seemed to me quite near to that goal.

--

---

From: S Moonesamy <[email-masked]>
Date: Wed, 13 May 2020 10:10:09 -0700

Hi Ben,
At 08:12 PM 12-05-2020, Ben Schwartz wrote:
>That seems quite contentious to me.  Decentralization of the DNS is 
>_also_ a privacy threat: running your own recursive leaks your IP to 
>every authoritative (far worse than ECS!), pinning yourself to a 
>unique recursive makes you uniquely identifiable as you move across 
>the network, and using a recursive whose identity is unknown is 
>obviously a privacy concern.

I commented about "centralization" within the context of IETF work on 
several occasions.  My opinion is likely clouded by past 
experience.  With respect to privacy, I spent around two years 
getting the IESG to take it seriously.

 From what I recall of what is written in RFCs, DNS is described as a 
distributed database.  There are some advantages of it being 
distributed, or if I may say so, decentralized.  For example, some 
countries might wish to have some degree of control over their 
ccTLD.  System failures do not generally affect a majority of users.

There are obviously privacy implications.  Within an IETF context, it 
would make surveillance easier if everything is one provider.

Regards,
S. Moonesamy

---

From: Andrew Campling <[email-masked]>
Date: Wed, 13 May 2020 21:46:53 +0000

>>every authoritative (far worse than ECS!), pinning yourself to a unique

>>recursive makes you uniquely identifiable as you move across the

>>network, and using a recursive whose identity is unknown is obviously a

>>privacy concern.

>several occasions.  My opinion is likely clouded by past experience.

>With respect to privacy, I spent around two years getting the IESG to

>take it seriously.

>distributed database.  There are some advantages of it being distributed,

>or if I may say so, decentralized.  For example, some countries might

>wish to have some degree of control over their ccTLD.  System failures

>do not generally affect a majority of users.

>There are obviously privacy implications.  Within an IETF context, it would

>make surveillance easier if everything is one provider.

I note that draft-arkko-arch-infrastructure-centralisation made some helpful observations regarding the dangers of centralisation, with specific points relating to DNS.  It included the following points in the recommendation section: "Where such centralised points are created, they will eventually fail, or they will be misused through surveillance or legal actions regardless of the best efforts of the Internet community.  The best defense to data leak is to avoid creating that data store to begin with".  This seems to be good advice to me.

Andrew

---

From: Andrew Campling <[email-masked]>
Date: Wed, 13 May 2020 22:19:49 +0000

On 13/05/2020 11:27 Vittorio Bertola <[email-masked]> wrote:

>> Il 12/05/2020 17:18 Stephane Bortzmeyer <[email-masked]<mailto:[email-masked]>> ha scritto:

>I disagree. There are IETF documents that provide policy-level analysis of complex

>technical issues and do so throughout the entire network architecture, both in terms

>of layers and in terms of hosts. For example, RFC 7754 has an entire section devoted

>to what happens within the endpoints and within applications that run on them.

>Also, RFC 6973, which is the document that this draft tries to apply, has an entire

>section of the guidelines (7.2) that instructs to discuss issues of user control, which

>is what 6.1.1.2 deals with. Actually, the first point of the section is:

>There even is an explicit reference to discussing how control and consent is handled outside of the protocol.

I also note that RFC 3552 (Guidelines for Writing RFC Text on Security Considerations) includes section 2.3 on systems security so does indeed look beyond the network.  So, alongside RFC 7754 and RFC 6973, there seem to be a good number of examples where the IETF has reached consensus on documents with scope that extends beyond the network.  I’m unclear why this one should not.

Andrew

---

From: Christian Huitema <[email-masked]>
Date: Wed, 13 May 2020 16:58:08 -0700

On 5/13/2020 3:19 PM, Andrew Campling wrote:
> I also note that RFC 3552 (Guidelines for Writing RFC Text on Security
> Considerations) includes section 2.3 on systems security so does
> indeed look beyond the network.  So, alongside RFC 7754 and RFC 6973,
> there seem to be a good number of examples where the IETF has reached
> consensus on documents with scope that extends beyond the network. 
> I’m unclear why this one should not.

Because we do not in fact have consensus on what to say.

Also, if we want to tackle the topic of centralization, it should
probably be best to decouple it from client system architecture. There
are many forces pushing centralization, and it is very unclear that
application configuration is the worst of them. For example, we see many
ISPs subcontracting their DNS services to big centralized providers. We
also see centralization of authoritative servers, with many web sites
getting their DNS services from big providers. We see centralization in
the TLD services, with many TLD registries  subcontracting operations to
specialized providers.

Which means it is probably much simpler to leave the client system
architecture discussions out of the rfc7626-bis draft, and start a
separate effort to describe centralization issues.

-- Christian Huitema

---

From: Brian Dickson <[email-masked]>
Date: Wed, 13 May 2020 17:49:30 -0700

On Tue, May 12, 2020 at 8:13 PM Ben Schwartz <bemasc=
[email-masked]> wrote:

>> also very imprecise.. I think this should be rewritten in a much more
>> neutral way.
>>
>> In any case, I don't know Mozilla's view on whether this is a specific
>> dig against them, but it is meant as a discussion on privacy impacts of a
>> In a market in which there are few choices, indeed this behaviour
>> promotes centralization: we know that most users do not change the
>> defaults, and if most users of a popular application start using a single
>> resolver in place of a broad set of local resolvers scattered around the
>> Internet, of course the resulting traffic pattern is more centralized.
>>
Please let me point out that there is a repeated false dichotomy, regarding
running your own resolver software.

There is one specific mode, which most resolver software supports:
forwarder.
The resolution chain would then be application - stub software - local
forwarder - [possible additional forwarders such as on home "routers" or
wifi devices] - resolver - {authority servers}.

In the forwarder mode, many/most of the features of the resolver are
preserved/exposed, including things like caching, DNSSEC validation, and
client-facing DoT/DoH.

The important distinction is, the resolver in forwarder mode does NOT talk
directly to the authority server (and thus leak IP information) but instead
talks to another resolver.

The reasons for doing something like this are hopefully obvious enough: the
user gets the best of both worlds, in terms of privacy and in terms of
control via the software choice and configuration.

(There are reasons to encourage forwarders instead of hyper-local resolvers
beyond the privacy issue, such as the scalability of the entire DNS
ecosystem, which relies to a large degree on having fewer resolvers than
there are end hosts on the Internet.)

Given this third option (versus total decentralization and maximal
centralization), the importance of including this topic is paramount for
the privacy issues it covers.

I think the document is mostly fine, and modulo tweaks in the very specific
area, I don't see any reason to remove any content, only at most small
wordsmithing changes to address any technical errors.

Brian

---

From: Rob Sayre <[email-masked]>
Date: Wed, 13 May 2020 20:52:44 -0700

On Wed, May 13, 2020 at 4:58 PM Christian Huitema <[email-masked]>
wrote:

> Considerations) includes section 2.3 on systems security so does indeed
> look beyond the network.  So, alongside RFC 7754 and RFC 6973, there seem
> to be a good number of examples where the IETF has reached consensus on
> documents with scope that extends beyond the network.  I’m unclear why this
> one should not.
>
>

Agree. There doesn't even seem to be consensus that this part of the
document concerns security. A lot of the terms in this thread, like "user"
and "security", are being stretched pretty far.

Some sections of this document read more like industry advocacy than an
IETF document to me. Advocacy is fine, but I am not sure it belongs in an
RFC.

thanks,
Rob