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

[Vittorio Bertola <[e-mail]>]

> Il 12/05/2020 17:18 Stephane Bortzmeyer <[e-mail]> ha scritto:
> 
> Yes, and I think I know now the root of the problem. 7626bis tries to
> go too far and, instead of discussing the DNS protocol and its privacy
> issues, now goes into end hosts and discuss what is done inside the
> machine, and what should be done. This is certainy interesting, and it
> certainly has consequences on privacy, user control, etc but:
> 
> 1) It is a bit outside IETF's domain, since it is not inside the
> network,

I disagree. There are IETF documents that provide policy-level analysis of complex technical issues and do so throughout the entire network architecture, both in terms of layers and in terms of hosts. For example, RFC 7754 has an entire section devoted to what happens within the endpoints and within applications that run on them.

Also, RFC 6973, which is the document that this draft tries to apply, has an entire section of the guidelines (7.2) that instructs to discuss issues of user control, which is what 6.1.1.2 deals with. Actually, the first point of the section is:

      "What controls or consent mechanisms does the
       protocol define or require before personal data or identifiers
       are shared or exposed via the protocol?  If no such mechanisms or
       controls are specified, is it expected that control and consent
       will be handled outside of the protocol?"

There even is an explicit reference to discussing how control and consent is handled outside of the protocol.

> 2) There is clearly no consensus inside IETF about it.

This is a different matter. However, there is also no consensus on dropping this part - certainly I would not agree. It does not make sense to have a "DNS Privacy Considerations" document that ignores parts of the problem. These issues are so interlinked that there is no clear single "more privacy" switch. Each of the technical solutions, both within the protocol and within its clients, could provide more or less privacy depending on a number of other considerations, some of which are not about technical protocol design but are nonetheless relevant. Either you analyze them in full, or the analysis is going to be incorrect and misleading.

> My personal opinion is now that the best way out of the problem is to
> drop discussions about internal (to the end host) issues.

Again, I disagree. The solution is to find reasonable compromise text that can be acceptable for all while not making anyone really happy. What was in the last draft seemed to me quite near to that goal.

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