[Integrity] [was: Re: First Public Working Draft announcement: Subresource Integrity]

On 03/21/2014 03:49 PM, Hill, Brad wrote:
> WebSec WG members,
> 
>   The WebAppSec WG at the W3C has recently announced a First Public Working Draft for "Subresource Integrity".
> 
> http://www.w3.org/TR/SRI/
> 
>   This specification describes a method to add metadata about the hash identity of resources (like script files and images) to HTML and specify policy about how to verify and manage such resources before they are added to a web resource's Document Object Model.


thanks for this heads-up about this draft.  I'm glad to see more work in
this area.

a few concerns spring to mind:

handling cross-origin errors
-----------------------------

section 6.3 mentions cross-origin data leakage -- i'm glad to see this
discussed.  However, it suggests that UAs SHOULD refuse to fire error
events on cross-origin resources.  This contradicts section 3.5.4, which
claims that if the C-S-P of the origin page has a failure-mode of
"block" or "fallback" (the only values available?) then the UA MUST
report a violation.

"report a violation" itself is linked to
http://www.w3.org/TR/CSP11/#dfn-report-a-violation, which says the UA
MUST fire a violation event.

how is a UA expected to resolve these contradictions? Or am i missing
some nuance that makes these non-contradictory?

hash algorithm agility
----------------------

hash function agility raises questions about future interactions; I'm
glad to see it mentioned in section 6.2, but i don't think the text
there is sufficient.

let's imagine a future where SHA-256 is deemed to be broken; how should
a user-agent deal with elements with an SHA-256-based integrity
attribute?  should the UA treat the element as though it had no
integrity tag at all (value="indeterminate")?  or should it treat the
element as though it was compromised (value="corrupt")?  If we choose
value="indeterminate" and the origin's integrity-policy has
"require-for-all", what should happen?

being explicit about how we will handle algorithm deprecation in the
future will make future transitions much less painful.

regards,

 --dkg