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

From: Sara Dickinson <[email-masked]>
Date: Wed, 26 Feb 2020 14:18:48 +0000

> On 23 Jan 2020, at 13:53, Eric Rescorla <[email-masked]> wrote:
> 
> On Thu, Jan 23, 2020 at 5:08 AM Sara Dickinson <[email-masked]> wrote:
> 
>> 
>> 
>> On 20 Jan 2020, at 22:37, Eric Rescorla <[email-masked]> wrote:
>> 
>> Review comments attached:
>> 
>> 
>> COMMENTS
>> S 3.1.
>> >      described above, and may not have any confidentiality requirements.
>> >      However, the same is not true of a single transaction or a sequence
>> >      of transactions; that transaction is not / should not be public.  A
>> >      typical example from outside the DNS world is: the web site of
>> >      Alcoholics Anonymous is public; the fact that you visit it should not
>> >      be.
>> 
>> Well, technically what you want to conceal is the origin of the
>> transaction or its linkage to other transactions. The existence of the
>> query for that A record isn't secret.
> 
> Suggest:
> 
> “that transaction (and specifically the origin of that transaction) is not / should not be public."
> 
> The parenthetical swallows the main sentence. The accurate thing to say is:
> 
> In general, the existence of a single query is not sensitive -- though there may be exceptions
> for some very low use domains. However, the origin of a given query may leak information
> about specific users and the ability to link queries reveals information about individual use
> patterns.

To fit with existing text suggest:

 However, the same is not true of a single transaction or a sequence
 of transactions; those transaction are not / should not be public. A single 
 transactions reveals both the originator of the query and the query 
 contents which potentially leaks sensitive information about a specific user. A
 typical example from outside the DNS world is: the web site of
 Alcoholics Anonymous is public; the fact that you visit it should not
 be.  Furthermore, the ability to link queries reveals information about individual use patterns. 

<snip>

> 
> 
>> 
>> 
>> 
>> 
>> S 3.4.2.
>> >      services available.  Given this, the choice of a user to configure a
>> >      single resolver (or a fixed set of resolvers) and an encrypted
>> >      transport to use in all network environments can actually serve to
>> >      identify the user as one that desires privacy and can provide an
>> >      added mechanism to track them as they move across network
>> >      environments.
>> 
>> I don't understand this paragraph. It's not the choice of specific
>> resolvers that leaks data, but the choice to turn on encryption, In
>> fact, from an identification purpose, the more resolvers that support
>> encrypted transport, the better signal this is.
> 
> This was driven by an observation that many early adopters set up their own DoT server and used that from all their devices, which could act as a way to identify that user. 
> 
> 1. This seems like an edge case.
> 2. We already have plenty of people running their own unencrypted resolvers for other reasons.

I can live with removing this text, but it does seem there is something to say about the fact configuring a single resolver for a device could differentiate a user….

> 
>> 
>> 
>> S 3.5.1..1.2.
>> >   
>> >      o  communicate clearly the change in default to users
>> >   
>> >      o  provide configuration options to change the default
>> >   
>> >      o  provide configuration options to always use the system resolver
>> 
>> I get that you think this is neutral, but all of this is equally true
>> about dynamic discovery via DHCP, it's just that that's the status
>> quo, so you don't notice it. In this context, this text is tendentious.
> 
> The first paragraph of section 3.5.1.1 talks about the variability of DNS resolution privacy with network (assuming DHCP). I can add some text there to better explain the status quo if you think it is needed. Suggest:
> 
> “Typically joining a new network requires some form of user action (e.g physically plugging in a cable or selecting a network in a OS dialogue) and so a user is also implicitly choosing to use the DHCP-provided resolver via this action too."
> 
> The user has no idea that such a DHCP resolver even exists. And you could say the same thing about the user's choice to install an application with its own resolver selection logic.
> 
> 
> I can’t think of a mobile or desktop OS that doesn’t allow users to override the DHCP provided DNS settings…. but I could text about that in section 5.1.1. if you really think it is needed?
> 
> This isn't about that. AFAICT most major applications also allow you to use the system resolver choices. Rather, the issue here is the repeated arguments in this discussion (which you implicitly accept above) that the current status quo somehow represents user choice whereas an application choosing its own resolver does not. And both this text and your proposed text implicitly takes a position on that.

I think that is reading quite a bit into the text however, to reduce any implicit misinterpretation I propose trying to further align the two sections… 

1) Replace the first paragraph in section 3.5.1.1 with the following:

"Given all the above considerations, the choice of recursive resolver has direct privacy considerations for end users.  Historically, end user devices have used the DHCP-provided local network recursive resolver. Because of this, the choice by a user to join a particular network  (e.g. by physically plugging in a cable or selecting a network in a OS dialogue) also determines the default system DNS resolver selection; the two are directly coupled in this model.

The vast majority of users do not change their default system DNS settings and so implicitly accept the network settings for DNS. The network resolvers have therefore historically been the sole destination for all of the DNS queries from a device. These resolvers may have strong, medium, or weak privacy policies depending on the network.  Privacy policies for these servers may or may not be available and users need to be aware that privacy guarantees will vary with network.

All major OS’s expose the system DNS settings and allow users to manually override them if desired.”

2) And replace the second paragraph of 3.5.1.1.2  with this:

"Such application-specific settings introduce new control points on end user devices for DNS resolution settings in addition to the historically used system settings discussed in Section 3.5.1.1. They therefore alter the DNS privacy considerations for the device by introducing additional destinations for DNS queries. 

Users will only be aware that a new control point (with new defaults) exists if an application clearly communicates this to the user on install or upgrade. 

The vast majority of users do not change default application-specific settings and so implicitly accept the application-specific settings for DNS. As with network resolvers, these resolvers may have strong, medium, or weak privacy policies depending on the application.  Privacy policies for these servers may or may not be available and users need to be aware that privacy guarantees will vary with each application. 

For users to have the ability to inspect and control the application-specific DNS settings in a similar fashion to the OS DNS settings, each application must also:

   o  expose the default settings to the user

   o  provide configuration options to manually override the default settings

   o  provide configuration options to always use the system resolver"

> 
> 
> The point in section 3.5.1.1.2  terms of privacy considerations is that any application that uses an application specific DNS setting introduces another control point on the device for the DNS resolution setting (which with the current offerings is independent of the network used), and if or how that is exposed is entirely up to the application. I suggest adding this text at the start of the second paragraph:
> 
> "Such application-specific settings introduce new control points on end user devices for DNS resolution settings in addition to the historically used system settings."
> 
> Well, I suppose this is true, but it's also true of (for instance) allowing the user to set a proxy, which we've done forever.
> 
>> 
>> 
>> S 3.5.1.1.2.
>> >   
>> >      Application-specific changes to default destinations for users' DNS
>> >      queries might increase or decrease user privacy - it is highly
>> >      dependent on the network context and the application-specific
>> >      default.  This is an area of active debate and the IETF is working on
>> >      a number of issues related to application-specific DNS settings.
>> 
>> This, too, could be said about the current situation.
> 
> See above. 
> 
> And my response above.
> 
> -Ekr
> 
> 
> Sara. 
> 
>> 
>> On Mon, Jan 20, 2020 at 1:47 PM Eric Vyncke (evyncke) <[email-masked] <mailto:[email-masked]>> wrote:
>> Thanks to Sara and Stéphane for the -04 revised I-D. 
>> 
>> After reading the -04, I think that most of the IETF Last Call comments are addressed (and consensus needs to be balanced -- even for informational document) and that the document sticks to facts.
>> 
>> But, as section 3.5.1 ("in the recursive resolvers") raised a lot of discussions during the first IETF Last Call, and as the authors reacted to those comments by deep changes in the text, let's have a new IETF Last Call before proceeding with IESG evaluation.
>> 
>> Again, thank you to the reviewers and the authors
>> 
>> Regards,
>> 
>> -éric
>> 
>> 
>> On 20/01/2020, 22:34, "IETF Secretariat" <[email-masked] <mailto:[email-masked]>> wrote:
>> 
>>     IESG state changed:
>> 
>>     New State: Last Call Requested
>> 
>>     (The previous state was Waiting for AD Go-Ahead::AD Followup)
>> 
>>     The previous last call raised several points. The authors have worked on those points and this new informational IETF draft has substantive changes; enough to go trigger a new IETF Last Call.
>> 
>>     -éric
>> 
>>     Datatracker URL: https://datatracker.ietf.org/doc/draft-ietf-dprive-rfc7626-bis/ <https://datatracker.ietf.org/doc/draft-ietf-dprive-rfc7626-bis/>
>> 
>> 
>> 
>> _______________________________________________
>> dns-privacy mailing list
>> [email-masked] <mailto:[email-masked]>
>> https://www.ietf.org/mailman/listinfo/dns-privacy <https://www.ietf.org/mailman/listinfo/dns-privacy>
>> 
> _______________________________________________
> dns-privacy mailing list
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/dns-privacy <https://www.ietf.org/mailman/listinfo/dns-privacy>

---

From: Eric Rescorla <[email-masked]>
Date: Fri, 28 Feb 2020 15:02:09 -0800

>  Alcoholics Anonymous is public; the fact that you visit it should not

I find this text a bit clumsy, but OK.

Furthermore, the ability to link queries reveals information about
> individual use patterns.

The key thing is "link queries as being from the same user"

>> This was driven by an observation that many early adopters set up their
>> own DoT server and used that from all their devices, which could act as a
>> way to identify that user.
>>
>
> I can live with removing this text, but it does seem there is something to
> say about the fact configuring a single resolver for a device could
> differentiate a user….
>

Sure, but this has nothing to do with DoH or DoT.

>> The first paragraph of section 3.5.1.1 talks about the variability of DNS
>> resolution privacy with network (assuming DHCP). I can add some text there
>> to better explain the status quo if you think it is needed. Suggest:
>>
>> “Typically joining a new network requires some form of user action (e.g
>> physically plugging in a cable or selecting a network in a OS dialogue) and
>> so a user is also implicitly choosing to use the DHCP-provided resolver via
>> this action too."
>>
>
> The user has no idea that such a DHCP resolver even exists. And you could
> say the same thing about the user's choice to install an application with
> its own resolver selection logic.
>
>
>
>> I can’t think of a mobile or desktop OS that doesn’t allow users to
>> override the DHCP provided DNS settings…. but I could text about that in
>> section 5.1.1. if you really think it is needed?
>>
>
> This isn't about that. AFAICT most major applications also allow you to
> use the system resolver choices. Rather, the issue here is the repeated
> arguments in this discussion (which you implicitly accept above) that the
> current status quo somehow represents user choice whereas an application
> choosing its own resolver does not. And both this text and your proposed
> text implicitly takes a position on that.
>
>
> I think that is reading quite a bit into the text however, to reduce any
> implicit misinterpretation I propose trying to further align the two
> sections…
>
> "Given all the above considerations, the choice of recursive resolver has
> direct privacy considerations for end users.  Historically, end user
> devices have used the DHCP-provided local network recursive resolver.
> Because of this, the choice by a user to join a particular network  (e.g.
> by physically plugging in a cable or selecting a network in a OS dialogue)
> also determines the default system DNS resolver selection; the two are
> directly coupled in this model.
>
> The vast majority of users do not change their default system DNS settings
> and so implicitly accept the network settings for DNS. The network
> resolvers have therefore historically been the sole destination for all of
> the DNS queries from a device. These resolvers may have strong, medium, or
> weak privacy policies depending on the network.  Privacy policies for these
> servers may or may not be available and users need to be aware that privacy
> guarantees will vary with network.
>
> "Such application-specific settings introduce new control points on end
> user devices for DNS resolution settings in addition to the historically
> used system settings discussed in Section 3.5.1.1. They therefore alter the
> DNS privacy considerations for the device by introducing additional
> destinations for DNS queries.
>
> Users will only be aware that a new control point (with new defaults)
> exists if an application clearly communicates this to the user on install
> or upgrade.
>

This reflects status quo bias. If you want to say this, then you need to
point out that essentially no OS clearly communicates that it is selecting
the DHCP resolver.

The vast majority of users do not change default application-specific
> settings and so implicitly accept the application-specific settings for
> DNS. As with network resolvers, these resolvers may have strong, medium, or
> weak privacy policies depending on the application.  Privacy policies for
> these servers may or may not be available and users need to be aware that
> privacy guarantees will vary with each application.
>
> For users to have the ability to inspect and control the
> application-specific DNS settings in a similar fashion to the OS DNS
> settings, each application must also:
>

This last point is wrong. The parallel here would be to use the *network
provided* resolver, not the system resolver. I would suggest that you be
less prescriptive about this and just say "applications will need to
provide user-visible options to configure the resolver." I would avoid
"must" (even in lower case) because this is a statement of fact, not a
normative one.

-Ekr

>
>
>
>> The point in section 3.5.1.1.2  terms of privacy considerations is that
>> any application that uses an application specific DNS setting introduces
>> another control point on the device for the DNS resolution setting (which
>> with the current offerings is independent of the network used), and if or
>> how that is exposed is entirely up to the application. I suggest adding
>> this text at the start of the second paragraph:
>>
>> "Such application-specific settings introduce new control points on end
>> user devices for DNS resolution settings in addition to the historically
>> used system settings."
>>
>
> Well, I suppose this is true, but it's also true of (for instance)
> allowing the user to set a proxy, which we've done forever.
>
>
>
>>
>> S 3.5.1.1.2.
>> >
>> On Mon, Jan 20, 2020 at 1:47 PM Eric Vyncke (evyncke) <[email-masked]>
>> wrote:
>>
>>> After reading the -04, I think that most of the IETF Last Call comments
>>> are addressed (and consensus needs to be balanced -- even for informational
>>> document) and that the document sticks to facts.
>>>
>>> But, as section 3.5.1 ("in the recursive resolvers") raised a lot of
>>> discussions during the first IETF Last Call, and as the authors reacted to
>>> those comments by deep changes in the text, let's have a new IETF Last Call
>>> before proceeding with IESG evaluation.
>>>
>>> On 20/01/2020, 22:34, "IETF Secretariat" <
>>> [email-masked]> wrote:
>>>
>>>     IESG state changed:
>>>
>>>     The previous last call raised several points. The authors have
>>> worked on those points and this new informational IETF draft has
>>> substantive changes; enough to go trigger a new IETF Last Call.
>>>
>>>     -éric
>>>
>>>     Datatracker URL:
>>> https://datatracker.ietf.org/doc/draft-ietf-dprive-rfc7626-bis/
>>>
>>>
>>>
>>> [email-masked]
>>> https://www.ietf.org/mailman/listinfo/dns-privacy
>>>
>>
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dns-privacy
>
>
>
>

---

From: Brian Dickson <[email-masked]>
Date: Fri, 28 Feb 2020 16:49:58 -0800

On Fri, Feb 28, 2020 at 3:15 PM Eric Rescorla <[email-masked]> wrote:

>> I can live with removing this text, but it does seem there is something
>> to say about the fact configuring a single resolver for a device could
>> differentiate a user….
>>
>
I think the text might be clearer if the bit "as one that desires privacy
and" were removed.
The issue isn't whether a specific user desires privacy, it is whether a
specific user can be identified and tracked.

This RFC update, is about privacy.
This particular section is on encrypted transport.
This paragraph is highlighting that configuring a static list of resolvers,
even if those use encrypted transport, may expose the user to privacy risks
due to that constant set of resolvers, as the user moves between networks.
And this risk is inversely proportional to the number of users of the
resolver.
Maybe this last bit needs to be added to emphasis why this is a risk?

It's about the fact that DoH/DoT don't protect against this or mitigate it,
even if the payload is encrypted. I.e. it doesn't not have anything to do
with DoH/DoT; it's bigger than DoH/DoT, and DoH/DoT don't fix the problem.

>>> The first paragraph of section 3.5.1.1 talks about the variability of
>>> DNS resolution privacy with network (assuming DHCP). I can add some text
>>> there to better explain the status quo if you think it is needed. Suggest:
>>>
>> The vast majority of users do not change their default system DNS
>> settings and so implicitly accept the network settings for DNS. The network

IMHO, this is fair, and probably adds a bit of clarity; perhaps some
wordsmithing on the start of 3.5.1.1 would benefit both this and other
subsections of 3.5.1.1.
Suggestion:

Old: "Historically, end user devices have used the DHCP-provided local
network recursive resolver, which may have strong, medium, or weak privacy
policies depending on the network."

New: "Historically, end user devices have used the OS-selected
recursive resolver,
whose identity is not exposed or discoverable. The OS may have been
configured with a static set of resolvers, or may use a DHCP-provided local
network resolver. This OS-selected resolver may have strong, medium, or
weak privacy policies, which for DHCP provided resolvers may depend on the
network."

The gist of this is, over-riding the default has effects that the
application cannot know, because the OS resolver choice is generally not
known, and by extension, the privacy policies cannot be known.

> "must" (even in lower case) because this is a statement of fact, not a

No, system resolver is accurate. In addition to not knowing what possible
resolver is offered by DHCP, the application can't know if DHCP (i.e.
network provided) is even being used -- the system could be using a static
choice of resolver, or even other non-DNS resolution services (e.g. NIS+).

Brian

>
>>
>>
>>
>>> The point in section 3.5..1.1.2  terms of privacy considerations is that
>> And my response above..

---

From: Eric Rescorla <[email-masked]>
Date: Fri, 28 Feb 2020 18:03:34 -0800

On Fri, Feb 28, 2020 at 4:50 PM Brian Dickson <[email-masked]>
wrote:

> This paragraph is highlighting that configuring a static list of
> resolvers, even if those use encrypted transport, may expose the user to
> privacy risks due to that constant set of resolvers, as the user moves
> between networks.
> It's about the fact that DoH/DoT don't protect against this or mitigate
> it, even if the payload is encrypted. I.e. it doesn't not have anything to
> do with DoH/DoT; it's bigger than DoH/DoT, and DoH/DoT don't fix the
> problem.
>

Yes, I agree with that, but this risk is generic to DNS even if you use
your own resolver (e.g., pihole) which we know people do. Therefore it does
not belong in this section as a risk of DoH/DoT..

>>> The user has no idea that such a DHCP resolver even exists. And you
>>> could say the same thing about the user's choice to install an application
>>> with its own resolver selection logic.
>>>
>>>
>>>
>>> "Given all the above considerations, the choice of recursive resolver
>>> has direct privacy considerations for end users.  Historically, end user
> network recursive resolver, which may have strong, medium, or weak
> privacy policies depending on the network."
>
> New: "Historically, end user devices have used the OS-selected recursive resolver,
> weak privacy policies, which for DHCP provided resolvers may depend on
> the network."
>

I don't believe this is accurate. In general there are (not that portable)
mechanisms for determining the DNS configuration, as is done in Chromium:
https://cs.chromium.org/chromium/src/net/dns/?sq=package:chromium&dr=CSs&g=0

> choice of resolver, or even other non-DNS resolution services (e.g. NIS+).

It turns out that there are at least three options here:

- Select your own resolver
- Select the resolver *configured into the system* (AIUI this is what
Chrome does).
- Use the system resolver via the conventional API calls.

-Ekr

> Brian
>
>>
>>>
>>>
>>>
>>>> The point in section 3.5..1.1.2  terms of privacy considerations is
>>>> that any application that uses an application specific DNS setting
>>>> introduces another control point on the device for the DNS resolution
>>>> setting (which with the current offerings is independent of the network
>>>> used), and if or how that is exposed is entirely up to the application. I
>>>> suggest adding this text at the start of the second paragraph:
>>>>
>>>> On Mon, Jan 20, 2020 at 1:47 PM Eric Vyncke (evyncke) <
>>>> [email-masked]> wrote:
>>>>
>>>>> After reading the -04, I think that most of the IETF Last Call
>>>>> comments are addressed (and consensus needs to be balanced -- even for
>>>>> informational document) and that the document sticks to facts.
>>>>>

---

From: Stephen Farrell <[email-masked]>
Date: Sat, 29 Feb 2020 02:07:28 +0000

Hiya,

> And this risk is inversely proportional to the number of users of the

I don't think the above is a good description of the
situation with DNS recursives.

My own intuition is that the risk vs. percentage of users
per recursive for a set of DNS recursive resolvers would
be more like a "U" shaped curve with risk-maxima near 1
user/recursive and also near 100% of users on one
recursive.

However, I'm not sure the idea of such a distribution
is so useful, as DNS recursives can be interdependent,
and traffic patterns will also matter.

Cheers,
S.