Re: [Doh] New Version Notification for draft-dickinson-doh-dohpe-00.txt

A few thoughts.  The recommendations seem pretty sensible, but I
remain a little uncertain about the utility of the draft.

3.2 recommends exclusive use of a connection for DoH.  That could run
counter to the goals because it would make traffic analysis easier.
Using the same connection for heterogeneous requests makes each
contribute to obscuring the others without relying on padding.

It's not clear from this recommendation whether this also recommends
connection reuse.  More on that below.

3.1 recommends the use of a single service.  That results in the
operator of that service getting access to a lot of information about
the activity of users.  Using different servers might be a better
result for privacy, making it harder for providers to use correlations
between requests to extract information.

The recommendation to suppress User-Agent appears to assume that there
is a valuable de-anonymization signal in that header field.  I don't
believe that to be true.  If there are relatively few User-Agent
strings exposed and the amount of information in that string is
minimal, this should not be a significant problem, meaning that the
effective anonymity set is large.  The same consideration applies to
the choice of GET or POST.

The recommendation against the use of cookies seems obvious, and it
might be true that cookies are the most hated feature of HTTP, but I
don't think that it achieves the goal.  Linking requests is pretty
powerful.  And as long as the client is able to control linkability,
cookies can be useful.  For the record, I don't think that this is a
bad recommendation, but it could be better grounded in concrete
rationale.  That is, there are many ways in which a client might link
one request to another and the client should be aware of those
mechanisms.  That gives the client a better ability to control this.
In addition to cookies, you should consider the use and reuse of
persistent connections, Alternative Services (which might be cached),
TLS session tickets, TFO cookies, and any other information that might
be used to link requests.

Overall, the set of recommendations here is pretty lightweight.  I'm
not sure that this is really that useful a document to publish.  The
application of this to a very specific usage of DNS is OK, but maybe
this is something advice is something that would be valuable more
generally.  This information is very well understood in the HTTP
community, but I concede that it's a little distressing that we don't
have a single document that captures all of this.

I note that the HTTP working group is revising its core specs.  Maybe
this represents an opportunity to improve the security considerations
of those documents.
On Wed, Jul 18, 2018 at 4:23 PM Ben Schwartz
<bemasc=40google.com@dmarc.ietf.org> wrote:
>
> I think this draft could use review from readers familiar with HTTP.  I hope that people with knowledge of HTTP will help us to understand whether this draft's recommendations would result in a significant increase in user privacy.
>
> For the draft's authors, I have a question: does this draft's "privacy threat model" include a DOH server that uses active measures to differentiate clients?  Or is it scoped only to passive discrimination between different client implementations?
>
> As for other issues, I think the draft might need to consider header order.  I also couldn't find an easy list of mandatory headers in RFC 7540, so that list might be worth repeating.
>
> On Wed, Jul 18, 2018 at 10:03 AM Sara Dickinson <sara@sinodun.com> wrote:
>>
>> Hi All,
>>
>> We’ve just submitted a very short draft outlining a privacy profile for DoH called DoHPE.
>>
>> It is very basic at the moment but it would be great to get some feedback on the idea here and to see if the WG sees this as something that should go through this group or head somewhere else. Since the guidelines are purely HTTP related, this does feel like the right audience to review the document at least in the first instance.
>>
>> Sara.
>>
>>
>> Begin forwarded message:
>>
>> From: internet-drafts@ietf.org
>> Subject: New Version Notification for draft-dickinson-doh-dohpe-00.txt
>> Date: 18 July 2018 at 09:58:48 GMT-4
>> To: "Sara Dickinson" <sara@sinodun.com>, "Willem Toorop" <willem@nlnetlabs.nl>
>>
>>
>> A new version of I-D, draft-dickinson-doh-dohpe-00.txt
>> has been successfully submitted by Sara Dickinson and posted to the
>> IETF repository.
>>
>> Name: draft-dickinson-doh-dohpe
>> Revision: 00
>> Title: DoHPE: DoH with Privacy Enhancements
>> Document date: 2018-07-18
>> Group: Individual Submission
>> Pages: 8
>> URL:            https://www.ietf.org/internet-drafts/draft-dickinson-doh-dohpe-00.txt
>> Status:         https://datatracker.ietf.org/doc/draft-dickinson-doh-dohpe/
>> Htmlized:       https://tools..ietf.org/html/draft-dickinson-doh-dohpe-00
>> Htmlized:       https://datatracker.ietf.org/doc/html/draft-dickinson-doh-dohpe
>>
>>
>> Abstract:
>>   This document describes DoHPE (DoH with Privacy Enhancements) - a
>>   privacy and anonymity profile for DoH [I-D.ietf-doh-dns-over-https]
>>   clients.  The profile provides guidelines on the composition of DoH
>>   messages, designed to minimize disclosure of identifying information.
>>
>>
>>
>>
>> Please note that it may take a couple of minutes from the time of submission
>> until the htmlized version and diff are available at tools.ietf.org.
>>
>> The IETF Secretariat
>>
>>
>> _______________________________________________
>> Doh mailing list
>> Doh@ietf.org
>> https://www.ietf.org/mailman/listinfo/doh
>
> _______________________________________________
> Doh mailing list
> Doh@ietf.org
> https://www.ietf.org/mailman/listinfo/doh