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 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
_______________________________________________
dns-privacy mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dns-privacy
