Re: SRI fail open behaviour

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
--Joel

On Sun, Jul 19, 2015 at 2:34 PM Francois Marier <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
>
>
>