- From: Devdatta Akhawe <dev.akhawe@gmail.com>
- Date: Sat, 27 Dec 2014 20:49:22 -0800
- To: Mike West <mkwst@google.com>
- Cc: Francois Marier <francois@mozilla.com>, "public-webappsec@w3.org" <public-webappsec@w3.org>
Imagine you are a web site owner and deploy SRI. 2 years from now, all versions SHA currently supported are broken. Browsers have switched over to supporting SHAwesome or whatever. But, since there is always that random user who doesn't update. What do you want the website to do? 1. Send SHA-2, SHA-3 values for all integrity attributes everywhere. This is not that great: since if sha-2, sha-3 have been broken, they don't provide the security we want them to provide. and we have added a chunk of processing and network overhead. 2. Use UA detection to only send headers to browsers known to support latest hash. But, the fork of Firefox with extra features doesn't get the attributes; new BlinkBrowser doesn't see these attributes and now has to fake UA. IMO, any place where we are designing a feature expecting people to use UA detection long term should raise red flags. This is actually non-trivial for implementors on the web application side. While the top 4-5 browsers take care of the vast vast majority of users, there is a long tail that is not insignificant and is an unnecessary pain. This is already painful for CSP deployment because older versions of Firefox break on a host source with a star in it and just fail close, breaking the site :( Don't get me wrong, fail close is more obviously secure for the current spec, but I am not sure it is a good long term bet, unless we want to explicitly support versioning. I am not sure this is convincing enough, but I definitely want to think about this a bit and would be curious how other specs, particularly security specs, handle this. While Postel's law might suggest failing open, there is obviously some tension with security. But, to actually achieve adoption (and thus security) maybe fail-open is necessary. cheers Dev On 26 December 2014 at 04:58, Mike West <mkwst@google.com> wrote: > Without thinking about it too hard, I'd vote for merging the "fail closed" > variant (https://github.com/w3c/webappsec/pull/120). > > We don't have a good way of distinguishing an awesome new hash function that > we don't yet support, and a bad old hash function that we don't want to > support without compiling a blacklist. I'd prefer not to do that. > > -mike > > -- > Mike West <mkwst@google.com>, @mikewest > > Google Germany GmbH, Dienerstrasse 12, 80331 München, Germany, > Registergericht und -nummer: Hamburg, HRB 86891, Sitz der Gesellschaft: > Hamburg, Geschäftsführer: Graham Law, Christine Elizabeth Flores > (Sorry; I'm legally required to add this exciting detail to emails. Bleh.) > > On Wed, Dec 24, 2014 at 2:45 AM, Francois Marier <francois@mozilla.com> > wrote: >> >> I've opened an issue around invalid metadata and unsupported hashes: >> >> https://github.com/w3c/webappsec/issues/119 >> >> as well as opened two pull requests for resolving the ambiguity: >> >> https://github.com/w3c/webappsec/pull/86 >> https://github.com/w3c/webappsec/pull/120 >> >> The gist of the issue is what should we do with an integrity attribute >> like: >> >> <script src="..." integrity="ni:///sha-1024;..."> >> >> Should it be ignored and the script loaded as with non-SRI enabled >> browsers (as if the integrity attribute wasn't there)? >> >> Or should it be ignored and cause the script to be blocked? >> >> I can personally see arguments both ways, so I'm curious what others >> think. >> >> Francois >> >> >
Received on Sunday, 28 December 2014 04:50:08 UTC