W3C home > Mailing lists > Public > public-web-security@w3.org > October 2011

RE: Security implications of network timing

From: Hill, Brad <bhill@paypal-inc.com>
Date: Tue, 4 Oct 2011 16:04:19 -0600
To: Tony Gentilcore <tonyg@chromium.org>, "public-web-security@w3.org" <public-web-security@w3.org>
Message-ID: <213E0EC97FE58F469BB618245B3118BB55342C1021@DEN-MEXMS-001.corp.ebay.com>

Keaton Mowery, Dillon Bogenreif, Scott Yilek, and Hovav Shacham have already done some work similar to this with JavaScript benchmarking.  So, to some extent, this kind of thing is already possible without the new spec.


More generally, I think it at least would be prudent to add to privacy and security considerations section that user agents allow users to opt-out of providing timing information, and that they opt-out implicitly in browsing modes intended to be privacy preserving.

-Brad Hill

> -----Original Message-----
> From: public-web-security-request@w3.org [mailto:public-web-security-
> request@w3.org] On Behalf Of Tony Gentilcore
> Sent: Tuesday, October 04, 2011 4:54 AM
> To: public-web-security@w3.org
> Subject: Security implications of network timing
> Hi Security Gurus,
> The Resource Timing[1] specification has just entered last call phase. It
> provides network timing details for each subresource loaded by a page, to
> wit, the HTTP redirect, DNS, TCP connect, HTTP request and HTTP response
> phases.
> We suspected that exposing this additional detail could improve the
> effectiveness of timing attacks like those described by Felten and
> Schneider[2]. So we have speculatively guarded these times with a same-
> origin restriction.
> But even with the same-origin restriction, other folks have speculated[3]
> these times could be used to improve the effectiveness of statistical
> fingerprinting. At the same time, developers who want to use the feature
> are concerned that the same-origin restriction is too crippling for their use-
> cases.
> So, we'd like to take a step back and develop a list of novel attacks that could
> be enabled by exposing network timing. Then we can put in the proper set of
> restrictions to prevent them. The problem is that none of the web
> performance working group participants have expertise in security or privacy.
> Are there folks in this group who would be willing to help us generate a list of
> novel attacks that could be exposed by network timing?
> Thank you,
> Web Performance Working Group
> [1] http://w3c-test.org/webperf/specs/ResourceTiming/
> [2] http://sip.cs.princeton.edu/pub/webtiming.pdf
> [3] http://lists.w3.org/Archives/Public/public-web-perf/2011May/0102.html
Received on Tuesday, 4 October 2011 22:05:04 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:26:19 UTC