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

[Eric Rescorla <[e-mail]>]

On Thu, Jan 9, 2020 at 10:03 AM Sara Dickinson <[e-mail]> wrote:

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

I understand that there are a number of people who would like to include
this material, but it isn't actually about DNS privacy in particular, nor
about DoH or DoT, which are just protocols, but about deployment models,
and so isn't really in scope here.

More generally, this document should not be trying to document or argue the
discussions that are happening about ADD.





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


See above.
-Ekr