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

[Sara Dickinson <[e-mail]>]

> On 7 Jan 2020, at 22:47, Eric Rescorla <[e-mail]> wrote:
> 
> 
> 
> On Tue, Jan 7, 2020 at 10:37 AM Sara Dickinson <[e-mail] <mailto:[e-mail]>> wrote:
> 
> 
>> On 19 Dec 2019, at 02:09, Eric Rescorla <[e-mail] <mailto:[e-mail]>> wrote:
>> 
>> 
>> 
>> On Wed, Dec 18, 2019 at 7:06 AM Sara Dickinson <[e-mail] <mailto:[e-mail]>> wrote:
>> 
>> 
>> > On 2 Dec 2019, at 00:00, Martin Thomson <[e-mail] <mailto:[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.

There was much follow up on this point, thank to everyone that contributed. My summary of those comments seem to be the there is a desire to include text covering the fact that centralisation is happening in many forms and has a mixed impact.  I suggest the following text 

“As with many other protocols issues around centralisation also arise with DNS. The picture is fluid with several competing factors contributing which can also vary by geographic region. These include:
* ISP outsourcing, including to third party and public resolvers
* regional market domination by one or only a few ISPs “

An increased proportion of the global DNS resolution traffic being served by only a few entities means that the privacy considerations for end users are highly dependant on the privacy policies and practices of those entities.”

I also previously proposed referencing draft-arkko-iab-internet-consolidation that Stephane mentioned, but Ekr objected.  

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

The point is to describe the privacy considerations of an entirely new deployment model for DNS that didn’t exist when the original RFC was published.

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

I’d argue the same as above, it is necessary to describe a new deployment model with new privacy considerations. This change is a reality for users of the Internet today so I think this document should make every effort to present an informative picture.

Sara.