RE: Security implications of network timing


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: [mailto:public-web-security-
>] On Behalf Of Tony Gentilcore
> Sent: Tuesday, October 04, 2011 4:54 AM
> To:
> 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]
> [2]
> [3]

Received on Tuesday, 4 October 2011 22:05:04 UTC