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

[Eric Rescorla <[e-mail]>]

+last-call

On Mon, Jan 20, 2020 at 2:37 PM 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.
>
>
>
>
>
> 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) <[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
>>
>