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

[Eric Rescorla <[e-mail]>]

On Mon, Mar 2, 2020 at 7:16 AM Sara Dickinson <[e-mail]> wrote:

>
>
> On 29 Feb 2020, at 02:03, Eric Rescorla <[e-mail]> wrote:
>
>
>
> On Fri, Feb 28, 2020 at 4:50 PM Brian Dickson <
> [e-mail]> wrote:
>
>>
>>
>> On Fri, Feb 28, 2020 at 3:15 PM Eric Rescorla <[e-mail]> wrote:
>>
>>>
>>>
>>> On Wed, Feb 26, 2020 at 6:19 AM Sara Dickinson <[e-mail]> wrote:
>>>
>>>>
>>>>
>>>> On 23 Jan 2020, at 13:53, Eric Rescorla <[e-mail]> wrote:
>>>>
>>>> On Thu, Jan 23, 2020 at 5:08 AM Sara Dickinson <[e-mail]>
>>>> wrote:
>>>>
>>>>
>>>>
>>>> On 20 Jan 2020, at 22:37, Eric Rescorla <[e-mail]> 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.
>>>>
>>>
>>> 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”
>>>
>>
> OK - will include that.
>
>
>
>>>
>>>> <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….
>>>>
>>>
>>> Sure, but this has nothing to do with DoH or DoT.
>>>
>>>
>> 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.
>>
>
> 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..
>
>
> I think the more general case is alluded to in the forth bullet point of
> section 3.4.1 without being called out specifically….
>
> One option would be update the first sentence of that bullet point to say
> “The recursive resolver can be a public DNS service (or a privately run DNS
> resolver hosted on the public internet).” and to add the following sentence
> to the end of the bullet point
>
> “It can be noted that the choice of a user to configure a single resolver
> (even when using an encrypted transport) can actually serve to aid tracking
> of that user as they move across network  environments."
>
> Then remove the fifth paragraph from section 3.4.2?
>

This seems close.

"It can be noted that if the user selects a single infrequently used
resolver (even when using an encrypted transport) it can actually serve to
aid tracking of that user as they move across network  environment"

I think we can agree that using Google Public DNS probably doesn't have
this property.


>
>>
>>>
>>>
>>>>
>>>>
>>>>>
>>>>> 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.
>>>>
>>>
>>> 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.
>>>
>>
>> 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.
>>
>
> 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
>
>
> I’m fine with Ekr’s original suggestion by replacing the last sentence in
> the first paragraph with the following:
>
> "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) typically
> updates a number of system resources - these can include IP addresses,
> availability of IPv4/IPv6,  DHCP server, and DNS resolver. These individual
> changes, including the change in DNS resolver, are not normally
> communicated directly to the user by the OS when the network is joined. The
> choice of network has historically determined the default system
> DNS resolver selection; the two are directly coupled in this model.
>

WFM.



>
>
>
>
>
>>
>>>
>>>
>>> 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"
>>>>
>>>
>>> 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.
>>>
>>
>
>> 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+).
>>
>
> 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.
>
>
> Suggest:
>
> "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 also needs to:
>
>    o  expose the default settings to the user
>
>    o  provide configuration options to manually override the default
> settings so that resolution is performed via
>           * user specified resolvers
>           * the resolvers configured into the system settings
>           * the system resolver via conventional API calls
>
> If all such applications are updated to use the system resolver, as
> described in the last bullet point, the device reverts to a single point of
> control for all DNS queries."
>

Hmm.... this seems unduly prescriptive. Perhaps.

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 also needs to expose the default settings
to the users and provide a configuration interface to change them.  If
this interface includes a setting to use the system resolver, then the
device can be reverted to a single point of control for all DNS
queries.

I think this removes the status quo bias. That said, I'd like to hear from
people
who implement their own resolver even for Do53. I know Chrome does
this and I believe it's quite common for SIP stacks due to performance
concerns with the system resolver.

-Ekr



> Sara.
>
>
> -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:
>>>>>
>>>>> "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) <
>>>>> [e-mail]> 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" <
>>>>>> [e-mail]> 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/
>>>>>>
>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> dns-privacy mailing list
>>>>>> [e-mail]
>>>>>> https://www.ietf.org/mailman/listinfo/dns-privacy
>>>>>>
>>>>>
>>>>> _______________________________________________
>>>> dns-privacy mailing list
>>>> [e-mail]
>>>> https://www.ietf.org/mailman/listinfo/dns-privacy
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>> dns-privacy mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/dns-privacy
>>>
>>
>