Re: [SRI] Comments on Subresource Integrity spec

On Mon, May 11, 2015 at 6:34 AM, Gervase Markham <gerv@mozilla.org> wrote:

> Who is right? In other words, who gets to mint new hash identifiers? The
> first browser to publish? Or does Subresource Integrity have to wait for
> the CSP people to publish a new version of their spec? Is that wise?
>

​"the CSP people" are the same people, the Web Application Security Working
Group is responsible for both specifications and responsible for keeping
them in sync. Yes, the editors differ and various members give different
levels of attention to one spec or the other, but at the end of the day the
working group members are responsible for what gets published as a
Recommendation.

Duplicating the information in the SRI spec rather than referencing CSP
would be a valid choice but doesn't change the fact that when SHA-3 is
adopted WASWG needs to specify how to reference it in one or both places.

>     * The spec does not give guidance as to whether, if integrity metadata
> >     is loaded in a privileged context, and is applied to an unprivileged
> >     document load, the user agent should consider the resulting context
> >     still to be privileged ("secure"). I can see the case for both
> answers.
>

​The spec may not be clear enough, but the issue has been resolved by the
working group. The presence of an integrity attribute should not change the
interpretation of whether the resource was loaded "securely", at least wrt
mixed content blocking or display.

I agree with you that section 5.1 addresses a different issue, and that
either the SRI or MIXED specs (or both) should be explicit on this point.
​


> > The idea is that if the hash function is broken, then it doesn't provide
> > any security, so checking the integrity is completely unnecessary (since
> > an attacker could just inject their own matching hash).
>
> I think this view has an unnecessarily binary understanding of "broken".
>

​I tend to agree with you. If our baseline is sha-256 and at some point in
the future it turns out to be weak it's still better to check it than not,
and breaking historic pages ("secure" fail closed) is unreasonably
punitive. We shouldn't support md5 or sha1, though, as it's not any harder
for authors to generate sha-256.
​

-
​Dan Veditz​