W3C home > Mailing lists > Public > public-webappsec@w3.org > January 2014

Re: [integrity]: latency tradeoffs

From: Joel Weinberger <jww@chromium.org>
Date: Wed, 15 Jan 2014 10:39:53 -0800
Message-ID: <CAHQV2KmN8HQV7ELdPcD1GONNbOSvWNj2iLANZFLMKWB-Xs93rA@mail.gmail.com>
To: Adam Langley <agl@google.com>
Cc: Mike West <mkwst@google.com>, "public-webappsec@w3.org" <public-webappsec@w3.org>
On Wed, Jan 15, 2014 at 7:21 AM, Adam Langley <agl@google.com> wrote:

> On Wed, Jan 15, 2014 at 4:16 AM, Mike West <mkwst@google.com> wrote:
> > 1. Performance isn't the goal. Integrity is the goal.
> Not quite, right? If integrity were the only goal then HTTPS provides
> that. I'm assuming that the desires motivating this are things like
> minimising backbone traffic (i.e. ISP caching), improving response
> times (i.e. using CDNs without fully trusting them).
 At the very least, performance would be a wonderful side effect, which is
what I view the entire caching portion about.

I also think that the latency point is that if we do this wrong, the
integrity check could provide a high latency cost for large files, so we
should want to reduce the latency even if we don't care about improving
performance over the status quo.

> > 2. I think the performance benefits of integrity would be focused on
> cache.
> > That is, the second load of a resource, regardless of its URL, could
> avoid
> > hitting the network entirely if we already have a matching resource
> locally.
> > For this case, we have the whole resource already, by definition.
> HTTPS resource can be cached equally well. If you're talking about
> using the cache as a content-addressable storage then I think that's
> too dangerous to allow. (As explored a little in "Origin confusion
> attacks". Also, talk to abarth about this.)
> Even if we do assume CAS behaviour, I don't believe that the metrics
> support this optimism. You should check with willchan and rvargas
> about observed disk cache behaviours.
> > I think this is problematic in most (all?) cases, given the nature of the
> > threat we're attempting to address. Trusting the resource to authenticate
> > itself doesn't provide much benefit if we're not sure we can trust the
> > resource in the first place.
> We're not trusting the resource to authenticate itself, but rather we
> are spreading the authentication data throughout the download itself
> in order to minimise processing latency. It's still the case that
> everything is authenticated by the single hash in the (trusted) HTML
> document.
> It's unclear whether the administrative overhead of doing this
> outweighs the latency advantages at this point.
> Cheers
Received on Wednesday, 15 January 2014 18:40:23 UTC

This archive was generated by hypermail 2.3.1 : Monday, 23 October 2017 14:54:04 UTC