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

From: Sara Dickinson <[email-masked]>
Date: Wed, 18 Jul 2018 10:02:44 -0400

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: [email-masked]
> Subject: New Version Notification for draft-dickinson-doh-dohpe-00.txt
> Date: 18 July 2018 at 09:58:48 GMT-4
> To: "Sara Dickinson" <[email-masked]>, "Willem Toorop" <[email-masked]>
> 
> 
> 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
>

---

From: Ben Schwartz <[email-masked]>
Date: Wed, 18 Jul 2018 16:22:35 -0400

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 <[email-masked]> wrote:

> 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: [email-masked]
> *Subject: **New Version Notification for draft-dickinson-doh-dohpe-00.txt*
> *Date: *18 July 2018 at 09:58:48 GMT-4
> *To: *"Sara Dickinson" <[email-masked]>, "Willem Toorop" <
> [email-masked]>
>
>
> 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://datatracker.ietf.org/doc/html/draft-dickinson-doh-dohpe
>
>
> Abstract:
> _______________________________________________
> Doh mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/doh
>

---

From: Sara Dickinson <[email-masked]>
Date: Thu, 19 Jul 2018 10:52:20 -0400

> On 18 Jul 2018, at 16:22, Ben Schwartz <[email-masked]> 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.

Completely agree.

> 
> 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?

Both of these.

> 
> As for other issues, I think the draft might need to consider header order.

Yes - a couple of other folks have mentioned that too.

>   I also couldn't find an easy list of mandatory headers in RFC 7540, so that list might be worth repeating.

There doesn’t seem to be a simple example in any draft I found so the current text is a bit of a cop-out. I was wondering if it would make more sense to have the list in draft-ietf-httpbis-bcp56bis-06 as a general clarification and then this document could reference that?

Or Stephane suggested pointing to RFC 7230 (plus a bit of RFC 7231) instead. But actually I now think example messages would be the most explicit way to show what DoHPE messages should look like.

Sara.

> 
> On Wed, Jul 18, 2018 at 10:03 AM Sara Dickinson <[email-masked] <mailto:[email-masked]>> wrote:
> Hi All,
> 
>> From: [email-masked] <mailto:[email-masked]>
>> To: "Sara Dickinson" <[email-masked] <mailto:[email-masked]>>, "Willem Toorop" <[email-masked] <mailto:[email-masked]>>
>> 
>> 
>> URL:            https://www.ietf.org/internet-drafts/draft-dickinson-doh-dohpe-00.txt <https://www.ietf.org/internet-drafts/draft-dickinson-doh-dohpe-00.txt>
>> Status:         https://datatracker.ietf.org/doc/draft-dickinson-doh-dohpe/ <https://datatracker.ietf.org/doc/draft-dickinson-doh-dohpe/>
>> Htmlized:       https://tools.ietf.org/html/draft-dickinson-doh-dohpe-00 <https://tools.ietf.org/html/draft-dickinson-doh-dohpe-00>
>> Htmlized:       https://datatracker.ietf.org/doc/html/draft-dickinson-doh-dohpe <https://datatracker.ietf.org/doc/html/draft-dickinson-doh-dohpe>
>> 
>> 
>> Abstract:
>> until the htmlized version and diff are available at tools.ietf.org <http://tools.ietf.org/>.
>> 
>> The IETF Secretariat
>> 
> 
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/doh <https://www.ietf.org/mailman/listinfo/doh>

---

From: Martin Thomson <[email-masked]>
Date: Thu, 19 Jul 2018 11:23:34 -0400

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=[email-masked]> wrote:
> 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.
>
>> Htmlized:       https://tools..ietf.org/html/draft-dickinson-doh-dohpe-00

---

From: Ben Schwartz <[email-masked]>
Date: Thu, 19 Jul 2018 11:39:03 -0400

> between different client implementations?

OK.  In that case, I think the draft would need to cover all the client's
error handling, redirect following, and retry logic, i.e. any behavior the
server could observe by generating targeted or malformed responses.  This
sounds challenging.

This is also true for the underlying DNS implementation.  Even without HTTP
or TLS, I suspect that by similar methods (using malformed responses or
exercising various unusual features), a recursive resolver could identify
the stub resolver software with high precision.

As Martin points out, the HTTP aspect of this is fairly widely applicable,
outside of DOH.  I think the same is probably true of the DNS side.  Thus,
one possibility would be to address those aspects separately.

> There doesn’t seem to be a simple example in any draft I found so the
> current text is a bit of a cop-out. I was wondering if it would make more
> sense to have the list in draft-ietf-httpbis-bcp56bis-06 as a general
> clarification and then this document could reference that?
>
> Or Stephane suggested pointing to RFC 7230 (plus a bit of RFC 7231)
> instead. But actually I now think example messages would be the most
> explicit way to show what DoHPE messages should look like.
>
> Sara.
>
>
>

---

From: Patrick McManus <[email-masked]>
Date: Fri, 20 Jul 2018 09:55:01 -0400

Hi Sara, Willem, interesting draft. I have two, perhaps slightly
inconsistent, high level thoughts and then a bunch of routine technical
comments.

1] The draft is pretty honest that what it really wants in its heart is an
HTTP tunnel to carry 7858 in. Implementations that desire that should
probably just do that via CONNECT - the procedure is well specified
already. Even the reason offered up for not doing so (Content-Negotiation)
cannot be done in a way consistent with the rest of the document (it
requires incremental deployment of Accept request headers as new formats
are deployed).

2] I think HTTPbis should consider this work right now. We added some text
to BCP56bis based on our previous discussions, but something directly in
the http-core work (which is a bis effort for 723x) could be much more
detailed and helpful. http-core is an adopted work item of HTTPbis that is
already a suite of documents, so whether it was a new document as part of
that or text within an existing one is pretty much just editorial.
Obviously the content of that output is determined by the WG (and
eventually the whole IETF), but I think it would be well received.

The content of your draft (perhaps modulo the padding issue) is equally
relevant to any use of web services as it is to doh, so relevant review by
the HTTP community seems paramount. I would be happy to work with you on it
in that forum.

OK - the smaller stuff:

3.1. this requirement doesn't really consider the possibility that resolver
choices are not equal - even from a privacy standpoint

3.2 this requirement may, as martin noted, result in weaker defense against
traffic analysis, and it might also result in more connections (for either
doh or for regular web) which probably have secondary leaks in the form of
sni or ocsp. this may not actually be a good idea if you are trading off
endpoint privacy against network privacy when the endpoiint can already do
correlation at the transport layer.

3.3 bcp56bis says don't enforce a minimum version so you run afoul of that
(core-doh makes this a should and lays out the reasons).. but if a doc says
>= h2, rather than == h2 it won't succeed in normalizing things for very
long anyhow as new versions come along.

3.5.1 normalizing user-agent to anything other than null is probably a bad
idea. The use of that field is for debugging and working around
implementation bugs - so if different implementations claim to be the same
thing it won't be effective. Empty is ok from that pov though you obviously
lose that feature of the ecosystem (which is widely used).

but there is so much else to think about in fingerprinting an h2
implementation. I'm not optimistic its solvable.

* priority schemes
* flow control crediting behavior
* settings values: max streams, windows, push, extensions
* stream id selection
* header encoding (hpack) choices

-- I 'm sure there are many more. I know I can easily play a game of "name
that implementation" when looking at most traces. Focusing on the user
fingerprinting problem instead of the implementation may be a more
tractable thing. I suppose the doc could just declare things below the
semantic layer out of scope, as it seems to have done for tls, tcp, and ip,
but  it runs the risk of defining something that can't be deployed to gain
its intended benefit. I actually think that line has already been crossed
by not addressing layers below http.

In any event, even this scope is 95% http rather than doh imo.

Cheerfully,
-P