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

[Sara Dickinson <[e-mail]>]

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

> 
> 
> 
> 
> 
> S 3.4.2.
> >      fingerprint [2] values can be used to fingerprint client OS's or that
> >      various techniques can be used to de-NAT DNS queries dns-de-nat [3].
> >   
> >      Note that even when using encrypted transports the use of clear text
> >      transport options to decrease latency can provide correlation of a
> >      users' connections e.g.  using TCP Fast Open [RFC7413] with TLS 1.2.
> 
> Why does this say TLS 1.2? Any use of TFO will have the same
> properties.
> 
> Perhaps you are thinking of TLS session tickets here?

Sorry - hangover from earlier text, will remove. The last previously agreed text was (in email of 31 Dec):

“Note that even when using encrypted transports the use of clear text transport options to decrease latency can provide correlation of a users' connections e.g. using TCP Fast Open [RFC7413]."

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

> 
> 
> S 3.4.2.
> >      identify the user as one that desires privacy and can provide an
> >      added mechanism to track them as they move across network
> >      environments.
> >   
> >      Implementations that support encrypted transports also commonly re-
> >      use sessions for multiple DNS queries to optimize performance (e.g.
> 
> Note: session is a technical term in TLS that refers to the
> association not the connection. I would say “connection"

Ack. 

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

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?

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

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

Sara. 

> 
> On Mon, Jan 20, 2020 at 1:47 PM Eric Vyncke (evyncke) <[e-mail] <mailto:[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] <mailto:[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/ <https://datatracker.ietf.org/doc/draft-ietf-dprive-rfc7626-bis/>
> 
> 
> 
> _______________________________________________
> dns-privacy mailing list
> [e-mail] <mailto:[e-mail]>
> https://www.ietf.org/mailman/listinfo/dns-privacy <https://www.ietf.org/mailman/listinfo/dns-privacy>
>