- From: Adam Langley <agl@google.com>
- Date: Wed, 15 Jan 2014 10:21:27 -0500
- To: Mike West <mkwst@google.com>
- Cc: "public-webappsec@w3.org" <public-webappsec@w3.org>
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