[SRI] Comments on Subresource Integrity spec

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?

* 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.

* 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?

* 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
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 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.

Gerv

Received on Thursday, 7 May 2015 12:33:59 UTC