Re: [Doh] [Ext] New Privacy Considerations Section Proposal

[Ted Hardie <[e-mail]>]

Hmm, we should probably pick one place to have this conversation.  In the
mean time, here's my reply to Paul:

It was only an example, and I would be happy to expand. That said, I think
this is the most likely source of leakage: folks using a general purpose
HTTP subsystem that carries information not needed for DOH requests.
Actually recommending data minimization there, rather than saying "it
should be considered" seems like a worthwhile thing to do in my personal
opinion.

Ted

On Wed, Jun 20, 2018 at 3:26 PM, Paul Hoffman <[e-mail]>
wrote:

> On Jun 20, 2018, at 3:14 PM, Ted Hardie <[e-mail]> wrote:
> >
> > Repeating the comment I made at Github:
> >
> > Is there a reason not to make a recommendation for the case of a
> DOH-only service?  The current text says:
> >
> > Implementations of DoH clients and servers need to consider the benefit
> > and privacy impact of all these features, and their deployment context,
> > when deciding whether or not to enable them.
> >
> > Would you consider a recommendation like "For DOH clients which do not
> intermingle DOH requests with other HTTP suppression of these headers and
> other potentially identifying headers is an appropriate data minimization
> strategy."?
>
> That could be added, but it would need a *lot* more text because your
> proposed text only deals with one layer (HTTP) while the text above it also
> talks about fingerprinting with TLS, TCP, and IP (in reverse order). The WG
> can decide whether adding recommendations for just one layer is worthwhile
> or possibly misleading about the overall privacy.
>
> --Paul Hoffman