Re: [Doh] New Privacy Considerations Section Proposal

[Sara Dickinson <[e-mail]>]

> On 21 Jun 2018, at 01:58, Patrick McManus <[e-mail]> wrote:
> 
> Hi Nusenu,
> 
> On Wed, Jun 20, 2018 at 8:06 PM, nusenu <[e-mail] <mailto:[e-mail]>> wrote:
> 
> It does not introduce new concerns when compared with HTTPS 
> but it does introduce new privacy converns when compared with 
> DNS over UDP, TCP or TLS (RFC7858),
> 
> I started to go down this path, but it pretty quickly became clear that comprehensive treatment of this kind of comparison is a different document - though I think describing things in layers does a decent job of pointing out where these various properties come into play. DoH needs to describe the properties of DoH.. the proposed text certainly doesn't try and hide from the fingerprintability of the http system doh is using.

But I also support (as other have voiced) at least a statement that it does introduce new concerns compared with 
DNS over UDP, TCP or TLS (RFC7858) which is missing from the new text.  Also a clear justification of why the design decisions were made (if I’ve heard the current arguments correctly).

I propose:

OLD:
“DoH inherits the privacy properties of the HTTPS stack and is not known to introduce new concerns beyond that of HTTPS."

NEW:
“As a deliberate design choice DoH inherits the privacy properties of
the HTTPS stack and is not known to introduce new concerns beyond that of HTTPS.
As a consequence, however, it does introduce new privacy concerns when compared
with DNS over UDP, TCP or TLS (RFC7858). The rationale for this decision is that 
retaining the ability to leverage the full functionality of the HTTP ecosystem is more
important than placing any constraints on this new protocol based on privacy considerations."

> The IP layer paragraph includes mitigations, the paragraphs about 
> the other layers are missing mitigations.
> 
> 
> those mitigations are there to provide context/scope to the addressing problem - not advice on how to mitigate it :) For most of the other features the mitigation is "don't use it" which of course has a cost.

But that cost would be low for a system resolver for example that could easily gain many benefits of DoH without needing to include hardly any of the HTTP bells and whistles. The current assumptions are very browser centric. 

I support adding the text as suggested by others e.g.
"In making this evaluation DoH clients should use the minimal set of data (e.g. headers, cookies) that can achieve the desired feature set whilst minimizing potentially identifying information being passed. For DOH clients which do not intermingle DOH requests with other HTTP messages suppression of these headers and other potentially identifying headers is an appropriate data minimization strategy.”

Sara.