Subject: #645: Privacy impact of connection coalescing

From: Mark Nottingham <[email-masked]>
Date: Fri, 21 Nov 2014 14:28:50 +1100

<https://github.com/http2/http2-spec/issues/645>

In private discussion with folks from Tor, a few privacy concerns came up which seemed good to document. I've made a pull proposing relevant changes:

<https://github.com/http2/http2-spec/pull/647>

Any thoughts?

Cheers,

--
Mark Nottingham   https://www.mnot.net/

---

From: Greg Wilkins <[email-masked]>
Date: Fri, 21 Nov 2014 14:59:27 +1100

Mark,

I can think of many ways that HTTP/1.1 can be used by a server to measure
the latency to a client - even more when TLS is used.   So nothing new
there.  Also HTTP1.1 has persistent connections, so multiplexing is not
really a new form of tracking, albeit maybe a little bit more effective now.

Warning that cookies and SSL ID's can be used to track users is OK because
they are part of the protocol.   But there are so many ways that network
meta data can be used to identify users that I don't think we can produce
an exhaustive list and a partial list has little value.

regards

On 21 November 2014 14:28, Mark Nottingham <[email-masked]> wrote:

> In private discussion with folks from Tor, a few privacy concerns came up
> which seemed good to document. I've made a pull proposing relevant changes:
>

-- 
Greg Wilkins <[email-masked]>  @  Webtide - *an Intalio subsidiary*
http://eclipse.org/jetty HTTP, SPDY, Websocket server and client that scales
http://www.webtide.com  advice and support for jetty and cometd.

---

From: Mark Nottingham <[email-masked]>
Date: Fri, 21 Nov 2014 15:50:39 +1100

> On 21 Nov 2014, at 2:59 pm, Greg Wilkins <[email-masked]> wrote:
> 
> 
> Mark,
> 
> I can think of many ways that HTTP/1.1 can be used by a server to measure the latency to a client - even more when TLS is used.   So nothing new there.  Also HTTP1.1 has persistent connections, so multiplexing is not really a new form of tracking, albeit maybe a little bit more effective now.
> 
> Warning that cookies and SSL ID's can be used to track users is OK because they are part of the protocol.   But there are so many ways that network meta data can be used to identify users that I don't think we can produce an exhaustive list and a partial list has little value.

The point is that these capabilities are new to this version of the protocol. 

> Greg Wilkins <[email-masked]>  @  Webtide - an Intalio subsidiary

---

From: Mark Nottingham <[email-masked]>
Date: Fri, 21 Nov 2014 16:50:27 +1100

> On 21 Nov 2014, at 4:49 pm, Greg Wilkins <[email-masked]> wrote:
> 
> 
> On 21 November 2014 15:50, Mark Nottingham <[email-masked]> wrote:
> My point is that they are not really new.     HTTP/1.1 can be used to measure latency (302 will do it, or looking at TLS handshake round trips, connection:close also can give such info). HTTP/1.1 had persistent connections that can be used to associated between 12% to 100% of a clients requests depending on how many connections they use.
> 
> Furthermore, I think that such lists are only useful if they are complete enumerations.   The harm of calling them out explicitly is that it may give users/implementers the false impression that these are the only privacy concerns they need to worry about.

Noted.

---

From: Greg Wilkins <[email-masked]>
Date: Fri, 21 Nov 2014 16:49:48 +1100

> The point is that these capabilities are new to this version of the

My point is that they are not really new.     HTTP/1.1 can be used to
measure latency (302 will do it, or looking at TLS handshake round trips,
connection:close also can give such info). HTTP/1.1 had persistent
connections that can be used to associated between 12% to 100% of a clients
requests depending on how many connections they use.

Furthermore, I think that such lists are only useful if they are complete
enumerations.   The harm of calling them out explicitly is that it may give
users/implementers the false impression that these are the only privacy
concerns they need to worry about.

regards

---

From: Martin Thomson <[email-masked]>
Date: Thu, 20 Nov 2014 21:19:24 -1000

> <https://github.com/http2/http2-spec/pull/647>

I like the correlation text, that's a real issue.  It's as much under
control of the client as many of the visible tracking capabilities
(cookies, JS, etc..), but highlighting what that means is worthwhile.

I'm lukewarm on the value of the SETTINGS/PING thing.  TCP window
scaling relies on knowing RTT, so another way of measuring it in a
less accurate way is of little intrinsic value.  It's certainly
harmless text inasmuch as it is correct, but it is only new if you
consider the layer in isolation and don't assume anything like (say)
lock-step request-response-request.  See
https://tools.ietf.org/html/rfc7323#section-3 for lower layers, and
JavaScript in general for higher.

I guess if you consider this as another hole to plug for the TOR
folks, then yes, but they have very special needs (and the skills to
match, no doubt).

---

From: Patrick McManus <[email-masked]>
Date: Fri, 21 Nov 2014 10:20:18 -0500

On Fri, Nov 21, 2014 at 2:19 AM, Martin Thomson <[email-masked]>
wrote:

> I like the correlation text, that's a real issue.

agreed - the term origin might be stronger than 'site' as currently used.

> scaling relies on knowing RTT, so another way of measuring it in a

h2 bits are e2e while TCP might not be thanks to CONNECT tunnels. I'm sure
you could game it through some kind of flow control back pressure
observation, but its not trivial.. tls has stuff to latch onto, but it can
be padded by concerned parties.. so I think its harmless and marginally
worthwhile to call out the issue with roughly the suggested text.

It might be stronger with 'peer' instead of client. Sometimes servers are
hiding - geographically speaking, and settings and ping are bi-di
mechanisms.

---

From: Amos Jeffries <[email-masked]>
Date: Sat, 22 Nov 2014 05:20:40 +1300

On 22/11/2014 4:20 a.m., Patrick McManus wrote:
> On Fri, Nov 21, 2014 at 2:19 AM, Martin Thomson wrote:
> 
>> On 20 November 2014 17:28, Mark Nottingham wrote:
>> I'm lukewarm on the value of the SETTINGS/PING thing.  TCP
>> window scaling relies on knowing RTT, so another way of measuring
>> it in a
>> 
> 
> h2 bits are e2e

That is wrong. Any h2 intermediaries will likely be varying the RTT
based on work being done for unrelated clients traffic. Stream windows
may also be scaled down/up at each hop depending on the various hops
capabilities. The way the h2 spec is written intermediaries have to do
a *lot* of transcoding work to pass traffic around.
 Clients workloads will impact on each others behaviour in randomly
varied amounts as things scale.
 The only thing e2e about the h2 transfer is per-stream window size.
And all that tells is how many bytes the network can afford to buffer
along the way.

In reality *HTTPS* (HTTP over TLS) is where the e2e predictability
problems start to occur in measurable amounts. Since clients traffic
is distinctly segregated from each other and A-to-B encryption
enforces large sections of the network to become measurable single-hops.

Amos

---

From: Patrick McManus <[email-masked]>
Date: Fri, 21 Nov 2014 11:39:26 -0500

> a *lot* of transcoding work to pass traffic around.

heh. true enough.

My assumption was that anyone concerned enough about rtt measurment to
consider it as part of the security consideration would only consider a
tunnel through an intermediary :)

---

From: Mark Nottingham <[email-masked]>
Date: Tue, 25 Nov 2014 15:00:27 +1100

I hear general agreement that adding these is a somewhat good idea, so I'm going to mark as editor-ready and direct Martin to consider the list feedback. If someone has an issue with what he does that they think is worth talking about, we can do that in the short review of -16.

Cheers,

> On 22 Nov 2014, at 3:39 am, Patrick McManus <[email-masked]> wrote:
> 
> 
> On Fri, Nov 21, 2014 at 11:20 AM, Amos Jeffries <[email-masked]> wrote:
> > h2 bits are e2e
> 
> My assumption was that anyone concerned enough about rtt measurment to consider it as part of the security consideration would only consider a tunnel through an intermediary :)
>

---

From: Martin Thomson <[email-masked]>
Date: Tue, 25 Nov 2014 11:31:40 -0800

> tunnel through an intermediary :)

That was my assumption also.  The particular situation we are talking
about allows *HTTP/2 peers* to measure latency to each other.  Of
course, this was, as Greg notes, a capability that was implicitly
available anyway, but there is no harm in acknowledging it.