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

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

+last-call

On Mon, Jan 20, 2020 at 2:37 PM 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.
>
>
>
>
>
> 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:
>
>> 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:
>>
>>     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
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/dns-privacy
>>
>

---

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

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

--