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

From: IETF Secretariat <[email-masked]>
Date: Mon, 20 Jan 2020 13:34:53 -0800

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/

---

From: "Eric Vyncke (evyncke)" <[email-masked]>
Date: Mon, 20 Jan 2020 21:45:08 +0000

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]> wrote:

    IESG state changed:

    
    
    -éric

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 20 Jan 2020 14:37:49 -0800

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.

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?

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.

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"

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.

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.

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.
>
>     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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dns-privacy
>

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 20 Jan 2020 15:22:45 -0800

+last-call

---

From: Vittorio Bertola <[email-masked]>
Date: Tue, 21 Jan 2020 15:46:19 +0100 (CET)

> Il 20/01/2020 22:45 Eric Vyncke (evyncke) <[email-masked]> ha scritto:
> 

First of all, I'd like to thank Sara for all the effort in rewriting a lot of text yet another time to address all the comments. I think the result is good, even if I would have preferred other text on certain things.

There is only a minor comment that I still have on 3.5.1. The new version has a part about DNS centralization risks, but it only addresses the risks deriving from the ISP market, not the newer ones coming from "application-specific resolver selection", which were mentioned in -03. I have two alternative text proposals to cover this:

1) in the bullet list in 3.5.1.1, add another bullet:

"* popular applications directing DNS traffic by default to specific dominant resolvers"

or 

2) in 3.5.1.1.2., last paragraph, just after "increase or decrease user privacy" and before the hyphen, add:

"and promote or counter centralization"

Given Eric's (not Éric's :-) ) comment on the requirements for user control in 3.5.1.1.2, i.e. that they also apply to the selection of non-encrypted resolvers today, it would be fine for me if they were extended to device/OS resolver configuration in general. In that case, I would plead for the addition of a point regarding the fact that the user should be enabled to configure the resolver for the OS and all the applications at once, in a single place.

I also have an editorial suggestion: to reduce the nesting of sub-sections in 3.5, perhaps you could break down section 3 into multiple first-level sections and do some renumbering, e.g.

3. -> 3.
3.1, 3.2, 3.3 -> 4.1, 4.2, 4.3 within "4. Risks in the DNS data"
3.4 -> "5. Risks on the wire"
3.5 -> "6. Risks in the servers"
3.6, 3.7 -> 7.1, 7.2 within "7. Other risks"

In any case, I think that we now have a solid document and hope we can release it soon.

-- 
 
Vittorio Bertola | Head of Policy & Innovation, Open-Xchange
[email-masked] 
Office @ Via Treviso 12, 10144 Torino, Italy

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 21 Jan 2020 06:49:39 -0800

On Tue, Jan 21, 2020 at 6:46 AM Vittorio Bertola <vittorio.bertola=
[email-masked]> wrote:

> First of all, I'd like to thank Sara for all the effort in rewriting a lot
> of text yet another time to address all the comments. I think the result is
> good, even if I would have preferred other text on certain things.
>
> There is only a minor comment that I still have on 3.5.1. The new version
> has a part about DNS centralization risks, but it only addresses the risks
> deriving from the ISP market, not the newer ones coming from
> "application-specific resolver selection", which were mentioned in -03. I
> have two alternative text proposals to cover this:
>
> Given Eric's (not Éric's :-) ) comment on the requirements for user
> control in 3.5.1.1.2, i.e. that they also apply to the selection of
> non-encrypted resolvers today, it would be fine for me if they were
> extended to device/OS resolver configuration in general. In that case, I
> would plead for the addition of a point regarding the fact that the user
> should be enabled to configure the resolver for the OS and all the
> applications at once, in a single place.
>

I would not be in favor of this. It's squarely in the zone of controversy.

-Ekr

> I also have an editorial suggestion: to reduce the nesting of sub-sections
> in 3.5, perhaps you could break down section 3 into multiple first-level
> sections and do some renumbering, e.g.
>
> 3. -> 3.

---

From: Sara Dickinson <[email-masked]>
Date: Thu, 23 Jan 2020 13:08:42 +0000

> On 20 Jan 2020, at 22:37, Eric Rescorla <[email-masked]> wrote:
> 

Suggest:

“that transaction (and specifically the origin of that transaction) is not / should not be public."

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

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

> association not the connection. I would say “connection"

Ack. 

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

> This, too, could be said about the current situation.

See above. 

Sara. 

> 
> On Mon, Jan 20, 2020 at 1:47 PM Eric Vyncke (evyncke) <[email-masked] <mailto:[email-masked]>> wrote:
> On 20/01/2020, 22:34, "IETF Secretariat" <[email-masked] <mailto:[email-masked]>> wrote:
> 
>     IESG state changed:
> 
>     Datatracker URL: https://datatracker.ietf.org/doc/draft-ietf-dprive-rfc7626-bis/ <https://datatracker.ietf.org/doc/draft-ietf-dprive-rfc7626-bis/>
> 
> 
> 
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/dns-privacy <https://www.ietf.org/mailman/listinfo/dns-privacy>
>

---

From: Sara Dickinson <[email-masked]>
Date: Thu, 23 Jan 2020 13:08:46 +0000

> On 21 Jan 2020, at 14:46, Vittorio Bertola <[email-masked]> wrote:
> 
> 

I’ll add this with a reference to section 3.5.1.1.2

> "and promote or counter centralization”

Sure.

> Given Eric's (not Éric's :-) ) comment on the requirements for user control in 3.5.1.1.2, i.e. that they also apply to the selection of non-encrypted resolvers today, it would be fine for me if the…

I don’t disagree that this a desirable feature but since the remit of the document is to describe the current situation, and this option is not available today AFAIK I’m not sure it should be included. I suggested to Ekr that text is added at the start of the second paragraph in this section that says:

"Such application-specific setting introduce new control points on the end user device for DNS resolution settings in addition to the historically used system settings.”

Would that address your concern?

> 3.6, 3.7 -> 7.1, 7.2 within "7. Other risks”

I like this suggestion and agree it would make the document structure better - thank you, will update.

Sara.

---

From: Vittorio Bertola <[email-masked]>
Date: Thu, 23 Jan 2020 14:16:50 +0100 (CET)

> Il 23/01/2020 14:08 Sara Dickinson <[email-masked]> ha scritto:
> 

Well, at least it mentions the issue, so I'm fine with it, thanks.

--

---

From: Eric Rescorla <[email-masked]>
Date: Thu, 23 Jan 2020 05:53:26 -0800

> “that transaction (and specifically the origin of that transaction) is not

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.

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

Yes, I think that's fine.

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

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

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

> This, too, could be said about the current situation.

And my response above.

-Ekr

---

From: Sara Dickinson <[email-masked]>
Date: Fri, 24 Jan 2020 17:01:21 +0000

Hi All, 

Please note that I will be out of the office next week and not reading email. I will continue to respond to IETF Last call comments on my return. 

Best regards

Sara. 

> On 20 Jan 2020, at 21:45, Eric Vyncke (evyncke) <[email-masked]> wrote:
>