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

[Ben Schwartz <[e-mail]>]

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

>
> Il 11/05/2020 21:35 Christian Huitema <[e-mail]> 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.
>

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.
>
> --
>
> Vittorio Bertola | Head of Policy & Innovation, Open-Xchange
> [e-mail]
> Office @ Via Treviso 12, 10144 Torino, Italy
>
> _______________________________________________
> dns-privacy mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dns-privacy
>