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

[Patrick McManus <[e-mail]>]

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












On Wed, Jul 18, 2018 at 10:02 AM, Sara Dickinson <[e-mail]> 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: *[e-mail]
> *Subject: **New Version Notification for draft-dickinson-doh-dohpe-00.txt*
> *Date: *18 July 2018 at 09:58:48 GMT-4
> *To: *"Sara Dickinson" <[e-mail]>, "Willem Toorop" <
> [e-mail]>
>
>
> 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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/doh
>
>