Re: [Doh] New Privacy Considerations Section Proposal

[Ted Hardie <[e-mail]>]

On Wed, Jun 20, 2018 at 4:54 PM, Adam Roach <[e-mail]> wrote:

> [as an individual]
>
> I agree with Patrick's analysis here, and think the proposed text (plus
> the "minimal set of data" statement below) is likely to serve the purpose
> well. In particular, I agree with Patrick that the various features that
> have been cited so far each serve a useful purpose, and that such purposes
> may have a place in DoH deployments. Giving implementors a heads up about
> the privacy trade-offs seems appropriate. Mandating (MUST or SHOULD) that
> DoH runs over a minimal profile of HTTP seems to remove several of the
> advantages of using HTTP at all.
>
> Note that this is not actually what I said--I said "run without specific
headers *when you are not interleaving DOH with other HTTP requests*".
That's a use case where some key advantages of using HTTP (traversal,
particularly) are maintained without affecting the other use cases which
might prefer more general integration.

Ted



> /a
>
> On 6/20/18 6:03 PM, Patrick McManus wrote:
>
>
>
> On Wed, Jun 20, 2018 at 6: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."?
>>
>>
> there are some practical problems there. Big picture you need to weigh the
> reasons these things get used in your implementation decisions. Its not
> like TLS didn't know they had built a tracker with session tickets, yet
> dprive recommended its use anyhow :)
>
> every http feature has a reason an implementation might want want it in
> doh. cookies can do useful things for auth. new compression algorithms
> (which create a fingerprint on introduction just as surely as UA does)
> enable better performance. etc.. UA strings have kept the web runinng, for
> good and bad, across many unanticipated bugs for many years.. I'm not
> saying those arguments win the day but its not really DoH's place to change
> the properties of HTTP. Alt-Service provides great load balancing and
> protocol evolution, but its basically a cache with a tracking implication
> too.
>
> It is an important goal of this work to leverage the HTTP ecosystem -
> stripping out all the HTTP parts and leaving a tunnel doesn't give it any
> value.
>
> The picture is also complicated by the end to end message semantics of
> http headers and how they interact with the hop to hop transport semantics
> of the client or server. i.e. the notion of intermingle is not e2e, but
> headers are. That's not really a driver, but something to keep in mind when
> considering the limitations of text.
>
> I'm more inclined in general to use words along the lines of "should use
> the minimal set of data that can achieve the desired feature set." if
> that's helpful, but I'm not eager to start working through individual
> design decisions.
>
>
>
>
> _______________________________________________
> Doh mailing [e-mail]://www.ietf.org/mailman/listinfo/doh
>
>
>