Re: [SRI] comments

Just a quick note that I wrote up
https://github.com/w3c/webappsec-subresource-integrity/pull/9 to address
most of your comments (and I responded to that issue to the comments I
didn't agree with). Thanks!
--Joel

On Tue, Oct 13, 2015 at 10:03 PM timeless <timeless@gmail.com> wrote:

> SRI [1] feedback
>
> > the default origin behaviour set to taint,
> en-us please: behavior
>
> > Additonally [sp], Brad Hill
>
> > If an attacker can trick a user into downloading content from a hostile
> server (via DNS poisoning, or other such means),
> > the author has no recourse.
> > Likewise, an attacker who can replace the file on the CDN server has the
> ability to inject arbitrary content.
> > Delivering resources over a secure channel mitigates some of this risk:
> with TLS, HSTS, and pinned public keys,
>
>
> DNS, CDN, TLS, TLA... would it be possible to provide a TableOfAcronyms ?
> Should TLS link to TLS1.2 or TLS1.3 [2]?
>
> > The following core rules are included by reference, as defined in
> Appendix B.1 of [ABNF]: WSP (white space) and VCHAR (printing characters).
>
> I'd expect a break after `:` and bullets for each item, as in:
>
> > This metadata consists of the following pieces of information:
> > * cryptographic hash function (“alg”)
> > * digest (“val”)
> > * options (“opt”)
>
> > At the moment, no options are defined.
> > However, future versions of the spec may define options
>
> of the => of this
>
> > When a hash function is determined to be insecure, user agents SHOULD
> deprecate and eventually remove support for integrity validation using that
> hash function.
>
> that hash function => it ??
>
> > If the fetch failed the CORS checks,
> > it won’t be available to us for integrity checking because
>
> > it won’t have loaded successfully.
>
> wouldn't
>
> > In order to mitigate an attacker’s ability to read data cross-origin by
> brute-forcing values via integrity checks, responses are only eligible for
> such checks if they are same-origin or are the result of explicit access
> granted to the loading origin via CORS. [CORS]
> > The user agent will refuse to render or execute responses that fail an
> integrity check, instead returning a network error as defined in Fetch
> [FETCH].
>
> You're inconsistent about placing []s before/after. I personally
> dislike the form you used w/ CORS, because it makes reading hard if
> there's a sentence after the []s.
>
> > On a failed integrity check, an error event is thrown.
>
> Is error an event, or an exception? (Exceptions tend to be thrown,
> events tend to be fired.)
>
> > Replace step 14.1 of HTML5’s “prepare a script” algorithm with:
>
> This is clear.
>
> > Whenever a user agent attempts to obtain a resource pointed to by a link
> element that has a rel attribute with the keyword of stylesheet, modify
> step 4 to read:
>
> `step 4` isn't clear, please add `of obtain a resource`...
>
> > Optimizing proxies and other intermediate servers which modify the
> responses MUST ensure that the digest associated with those responses stays
> in sync with the new content.
>
> Proxies have a tendency to do really stupid upgrades of insecure
> content. e.g. causing browsers to not see broken certificate warnings.
>
> There should be a note explaining what to do when content doesn't
> validate...
>
>
>
>
>
>
> [1] https://w3c.github.io/webappsec-subresource-integrity/
> [2] https://tlswg.github.io/tls13-spec/
>
>