Re: [dns-privacy] Review of draft-ietf-dprive-rfc7626-bis-03 - Section 3.5.1.1 Comments

[Eric Rescorla <[e-mail]>]

On Tue, Jan 7, 2020 at 10:37 AM Sara Dickinson <[e-mail]> wrote:

>
>
> On 19 Dec 2019, at 02:09, Eric Rescorla <[e-mail]> wrote:
>
>
>
> On Wed, Dec 18, 2019 at 7:06 AM Sara Dickinson <[e-mail]> wrote:
>
>>
>>
>> > On 2 Dec 2019, at 00:00, Martin Thomson <[e-mail]> wrote:
>>
>
> <snip>
>
>
>> Suggest replacing the last 4 paragraphs of this section with the
>> following text.
>>
>
> I can't say I like this very much.
>
>>
>> “It has been pointed out that should the trend towards using large public
>> resolvers increase, an increased centralisation of DNS resolution services
>> will result.
>>
>
> Well, it's been pointed out, but it's not at all clear that it's true, due
> to the large amount of centralization of ISPs in certain areas, so no, I
> don't think this document should make this claim.
>
>
> To address the more general problem I suggest:
>
> “Should the trend away from using ISP managed resolvers to using a small
> set of large public resolvers continue, then an increased proportion of the
> global DNS resolution traffic will to be served by only a few entities.
> Some potential impacts of centralisation within the Internet Infrastructure
> are outlined in [I-D.draft-arkko-arch-infrastructure-centralisation] and
> include some privacy related considerations. "
>

Yeah, my point is that I don't agree with this. Right now there is a lot of
ISP centralization and the move of some of that traffic to public resolvers
potentially decreases centralization at the margin. I certainly don't agree
with citing draft-arkko, which is not at all a neutral or factual source,
so this is just a way of incorporating by reference material which doesn't
have consensus.



An increasing number of applications are offering application-specific
>> encrypted DNS resolution settings, rather than defaulting to using only the
>> system resolver. Due to a lack of a standardized discovery mechanism for
>> DoH and Strict DoT servers, applications that do so are currently limited
>> to using hard coded lists of resolvers and a variety of heuristics and
>> resolvers are available in different applications. At the time of writing,
>> efforts to provide standardized signalling mechanisms for applications to
>> also discover the services offered by local resolvers are in progress
>> [I-D.ietf-dnsop-resolver-information]. Note that an increasing numbers of
>> ISPs are deploying encrypted DNS, for example see the Encrypted DNS
>> Deployment Initiative [EDDI].
>>
>
> I'm not sure what the point of this text is, but it seems kind of
> confusing. In particular, it's not the case that the primary reason that
> Firefox uses a hardcoded list is because there is no standardized discovery
> mechanism.
>
>
> To clarify I suggest:
>
> “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 recognised DoH/DoT
> servers.
>
> There is currently no standardized discovery mechanism for DoH and Strict
> DoT servers so applications that might want to dynamically discover such
> encrypted services are not able to. At the time of writing, efforts to
> provide standardized signalling mechanisms for applications to also
> discover the services offered by local resolvers are in progress
> [I-D.ietf-dnsop-resolver-information]. Note that an increasing numbers of
> ISPs are deploying encrypted DNS, for example see the Encrypted DNS
> Deployment Initiative [EDDI]."
>

I don't object to this text, but what's the point?


Everything after this just seems to pre-empt discussions that are ongoing
> and haven't reached consensus.
>
>
>> Application-specific changes to default destinations for users' DNS
>> queries might increase or decrease user privacy - it is highly dependant on
>> the network context and the application-specific default. This is an area
>> of active debate.
>>
>> In order that users are aware of and can control such changes it is
>> highly desirable that applications
>> * communicate clearly the change in default to users
>> * provide configuration options to change the default
>> * provide configuration options to always use the network provided
>> resolver
>>
>> The IETF is working on a number of issues related to application-specific
>> DNS settings. For example there have been discussions on the IETF ADD
>> mailing list [ADD] and a proposal for a new ABCD working group [ABCD].”
>>
>
>
> The goal here is to make the readers of the document aware of ongoing work
> even where consensus isn’t reached, which I think the first and third
> paragraphs do. The bullet points are meant to raise user awareness so if
> you really feel it necessary I propose changing the text as follows
>
> OLD: “In order that users are aware of and can control such changes it is
> highly desirable that applications"
>
> NEW: “Users will only be aware of and have the ability to control such
> changes if applications provide the following functions:”
>
> Attempting to stick to be factual here rather an asserting anything
> anything about consensus. Please suggest text if you have a better
> description of the issue.
>

My position is you should strike this text, not attempt to rewrite it. In
general, the history of trying to neutrally document controversial issues
in IETF is not very encouraging, and in this case it's quite unnecesary.

-Ekr


> Sara.
>
>
>