Re: SRI fail open behaviour

On 7/27/15 2:36 PM, Joel Weinberger wrote:
> Resurrecting this thread from the dead, as per our WebAppSec call 
> earlier today. I basically agree with Francois's points from earlier, 
> and I've inlined a few extra comments below.
>
> It seems to me that we're all in consensus that without CORS, SRI 
> should fail closed, so I think we should (and are) making that change 
> in the spec draft. Thus, the remaining open questions  from this 
> thread are, I believe:
>    1) Should crossorigin=anonymous be implicit in all requests (unless 
> same-origin or explicitly set by the developer?
>    2) Should it fail closed on bad hash algorithms as well?
>
> To (1), there doesn't appear to be consensus (although notably I 
> believe all of the editors agree it should *not* be implicit). I'm not 
> sure how to resolve this at this point, so any suggestions would be 
> welcome. My thought is that since this would be an additional 
> "feature," we should default to not include it if we can't come to 
> consensus, but I'm biased since I don't want it anyway :-)
>
> To (2), again, Brian doesn't appear to agree with this, but I believe 
> that we actually already came to consensus on failing open for an 
> unknown algorithm quite some time ago, and I feel strongly that this 
> decision should remain: 
> http://www.w3.org/2015/02/23-webappsec-minutes.html#item07
I agree that we should fail open for unknown algorithms.  It doesn't 
make sense to have the load succeed in a browser that doesn't support 
SRI and then block it a browser that does support SRI but doesn't 
support SHA-3 (for example) yet.  If we fail open in browsers that don't 
support SRI, we should fail open in browsers that don't support a 
specific hash algorithm.


>
> On Sun, Jul 19, 2015 at 2:34 PM Francois Marier <francois@mozilla.com 
> <mailto:francois@mozilla.com>> wrote:
>
>     On 18/07/15 13:44, Brian Smith wrote:
>     >     - Chrome 80 will load this just fine because it implements
>     "sha3"
>     >     - IE 9 will load it too because it doesn't have support for
>     SRI at all
>     >     - Firefox 42 would block it because it supports SRI but not sha3
>     >
>     >
>     > All three would be doing the right thing. The web page is saying "I
>     > don't trust the server. I would rather have the load fail than
>     have you
>     > load content that doesn't have a SHA-3 hash of 'Gk5l2Bi....'."
>     If the
>     > page author wanted Firefox 42 to be able to load the page, then they
>     > would test in in Firefox 42, see that it doesn't work, and then
>     either
>     > add a SHA-2 hash or decide that SHA-2 is too unsafe to rely on.
>
>     That's one way of explaining what the author intended to do.
>     Another is
>     that the author was keen to move to a better hash algorithm and didn't
>     think about (or test with) older versions of Firefox. From a web
>     compatibility point of view, Firefox is broken and Chrome and IE9 are
>     just fine.
>
> I disagree with Brian's description of likely developer intent. Since 
> integrity will not work on old browsers, you'd have to use another 
> mechanism (maybe XHR + manually check the integrity) to actually check 
> the integrity on old user agents. In fact, the entire integrity 
> attribute feature has been developed, almost by definition, with the 
> property "enforce the integrity if the integrity available in the user 
> agent."
>
> I think Francois's point is correct as well. It is possible to 
> download every browser possible to test your page on, but in practice 
> it won't happen, and one of the worst things the integrity attribute 
> can do would be break otherwise functional pages.
>
>
>     > From a usability standpoint, it is hard to see why a developer
>     would add
>     > an integrity attribute at all unless they want the fail-closed
>     behavior.
>     > It's much harder to write a proper test that every integrity
>     attribute
>     > has the correct syntax. However, it is pretty easy to notice
>     when your
>     > JS code doesn't run because a typo in the integrity attribute
>     blocked
>     > the load.
>
>     It's not as good, but there is another way to spot the typo: console
>     warnings.
>
>     > Note that [MIX] has fail-closed behavior: if you make a typo
>     "http://"
>     > instead of "https://" then the resource does not load.
>
>     Sure, but the MIX spec would be a no-op if it were to fail open :)
>
>     Francois
>
>