Re: [SRI] Comments on Subresource Integrity spec

Thanks for the comments! Response inlined below.
--Joel

On Thu, May 7, 2015 at 5:36 AM Gervase Markham <gerv@mozilla.org> wrote:

> Hi,
>
> I'm happy that this document is progressing :-)
>
> * Is it intentional that the spec does not mandate support for a
> baseline set of hash algorithms?
>
In
https://w3c.github.io/webappsec/specs/subresourceintegrity/#the-integrity-attribute-1,
in particular the production for hash-algo, which references the CSP spec
and its definition of hash algorithms, so I believe it implicitly does.

>
> * Is there somewhere I can read about the decision to defer support on
> elements other than <link> and <script> to a future version? It seems to
> me that supporting <a download href=""></a> would be a particularly
> valuable addition, over and above the other elements ruled out of scope.
>
There are several discussions on this list. In particular, search for a
message from lcamtuf@google.com, who addresses this.

>
> * The spec does not say how to form the identifying tag for a hash
> function - e.g. converting "SHA-256" into "sha256". This may seem
> simple, but the possible variants of SHA-3 are still not defined (AIUI),
> and so there may be ambiguity here. The CSP document punts on this too,
> simply defining 3 values - "sha256", "sha384" and "sha512". Is this
> their problem, or something to be addressed by the spec?
>
I don't think I understand the question. In the CSP spec,
https://w3c.github.io/webappsec/specs/CSP2/#source-list-valid-hashes
defines a conversion of the hash algorithms in the syntax into explicit
hash functions.

>
> * 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.
> There is no security loss in loading jQuery from a CDN using
> integrity-protected HTTP. There may be a small privacy loss (e.g. the
>
There is no privacy in the transport, so there is a major security loss. I
believe
https://w3c.github.io/webappsec/specs/subresourceintegrity/#unprivileged-contexts-remain-unprivileged-1
does address this, making it explicit that unpriviliged contexts remain
unprivileged.

> Referer header on the request, unless suppressed). But for more tailored

content, the loss is potentially greater. Still, it would be useful for
> the document to comment on this.
>
> * The document says user agents should "deprecate support for those
> functions shown to be insecure". What would that look like in practice,
> given that the alternative to using some integrity metadata is just
> loading the resource anyway? Let's say SHA256 was supported, then
> discovered to be weak. And the UA encounters a link with only SHA256
> integrity metadata. Why would the UA _not_ want to validate the resource
> against that metadata? It can't hurt. I mean, perhaps a warning could be
> printed to the error console, but that's pretty weak for "deprecation".
>
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).

For Chrome, I imagine we would log to the console if a
once-supported-but-no-longer-supported algorithm is used.

>
> * The ABNF for the integrity attribute allows option names without
> values, but it seems that it requires the = sign even when there's no
> value. That seems like a bug? It also doesn't seem to allow multiple
> options for a hash - the option-expression is not allowed multiple
> times, and no option separator is defined. In fact, & is an
> option-value-char so it could not be used as things stand. Perhaps
> semicolon? In general, it would be good to have a non-normative
> fictional example of option use, even if none are defined in the spec.
>
I believe the production does allow for multiple options, using "?" as a
separator. I don't think it's a bug to leave in the '=' sign; we wanted it
to be explicit that the value should be empty.

>
> Gerv
>
>