W3C home > Mailing lists > Public > public-webappsec@w3.org > October 2015

[SRI] comments

From: timeless <timeless@gmail.com>
Date: Wed, 14 Oct 2015 01:01:17 -0400
Message-ID: <CACsW8eG5tn+pDXTPr4McbfjOYvbLiiygSUi4ukHaGZ+Z71F-tw@mail.gmail.com>
To: "public-webappsec@w3.org" <public-webappsec@w3.org>
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/
Received on Wednesday, 14 October 2015 05:01:46 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:54:52 UTC