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

[Brian Dickson <[e-mail]>]

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

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