Re: [integrity]: latency tradeoffs

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).

> 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

AGL

Received on Wednesday, 15 January 2014 15:22:14 UTC