Re: [SRI] Updates to the spec and outstanding issues

Hi,

FWIW this seems really good; much more concise than it used to be. 

A few nits and questions below (reading the 12 March ED).

* 3.3.1 is "Apply algorithm to resource" and elsewhere -- given you're using the term incorrectly as per the HTTP and URL specs, but correctly as per HTML5, it might be good to either a) explicitly define "resource" in 2.1 Key Concepts and Terminology, or b) use "representation" or "payload" as appropriate.

* 3.2.2 Priority says "That is, getPrioritizedHashFunction(a, b) MUST return..."  Does this imply that a function called that is required to be implemented? If so, where is it defined?

* Generally, the spec seems somewhat RFC2119-happy; just because it's natural english to say "must" or "should" in a sentence doesn't mean it's a conformance requirement.

* The specification of how headers affect eligibility in section 3.2.2 needs some work; right now it mixes in request and response headers indiscriminately (see above re: "resource").  Also, how does HTTP authentication affect integrity?

* 3.6 The integrity attribute - There needs to be non-optional whitespace between the terminal option-expression and the first hash-expression; making the ABNF something like:

integrity-metadata = *WSP [ option-expression *( 1*WSP option-expression ) 1*WSP ] hash-expression ...

* Also, media-types can contain considerably more characters than you allow in option-value; see <http://httpwg.github.io/specs/rfc7230.html#field.components> (it's token).

* 3.8 Handling Integrity Violations defines a CSP directive that controls whether integrity violations are blocked or just reported. However, CSP already has a mechanism to control block vs. reporting, so this is confusing. E.g., what if "integrity-policy block" occurs in the CSP report-only header? Has there been discussion of just defining an "integrity" directive, and letting the header it occurs within determine how a violation is handled?

* 4. Proxies has clients add CC: no-transform in hopes that proxies won't modify the response body, but that's not how it works: <http://httpwg.github.io/specs/rfc7230.html#message.transformations> (no-transform only applies to the message it occurs within).

* Integrity data will be easier to add in some server-side scenarios if it's possible to convey it in HTTP headers on the response, rather than in the HTML (or CSS, or JS). For example:

HTTP/1.1 200 OK
Content-Type: text/html
Link: <https://widgets.example.com/foowidget>; rel="stylesheet"; type="text/css"; integrity="..."
...

Has this been discussed?

Also see below - 

> On 10 Mar 2015, at 10:03 am, Devdatta Akhawe <dev.akhawe@gmail.com> wrote:
> 
> Hi everyone
> 
> As we progress to SRI last call, I wanted to update everyone on a few changes to the spec and current status/open-issues. I would love to get feedback; but to help the discussion, please kick off a new thread for individual issues in this email instead of responding directly on this thread (or just respond on Github if you prefer). 
> 
> Changes in the last few weeks the tl;dr version is:
>  • We now use the CSP format for specifying hashes (base64, not base64uri)

3.2.1 Agility still says "...the following ni URLs..."

3.3.3 Still talks about a "set of valued "named information" (ni) URLs..."

>  • SRI doesn't officially require HTTPS, but the spec now notes the security issues with not using HTTPS as well as the spec will only use SSL in the examples etc. This is tricky and we definitely want to explain this correctly, an issue which is currently open
>  • Unsupported/unknown hashes no longer break: this allows applications to support the latest and greatest hash functions without having to worry about some old browser breaking. This was previously discussed on the list and agreed upon and this change just made that more clear.
>  • Since we only support scripts and styles, the hello world example in the spec changed to use a script instead of text/plain.
>  • The require-for-all directive was removed. It really should be require-for-all per resource type; otherwise, app authors write require-for-all and tomorrow a UA adds support for images in SRI and everything breaks. We will look at something like require-for-all in v2.
>  • Explicitly removed caching as a goal of the SRIv1 spec, since the spec doesn't do this nor does any implementation.

1. Introduction still says "Moreover, integrity metadata may also be useful for purposes other than validation. User agents may decide to use the integrity metadata as an identifier in a local cache..."

I think it's best to remove this, as it's speculative.

> Open issues/PRs
>  • There is no example example  violation report in the spec. 
>  • Currently, a resource is eligible for SRI if it is same-origin, or allowed via CORS, or is "publicly-cacheable". That last part is a bit confusing and unclear and Anne doesn't agree that it is secure. I also think it is confusing and unclear and the spec should just stick to CORS. What do others think? 
>  • The SRI spec currently doesn't enforce the mime-type and should say something like "insist on this mime type, even after sniffing". Unfortunately, content-type sniffing (afaik) isn't really spec'ed so it is not clear how to put that in the spec. 
>  • SRI currently doesn't support objects for v1. Should this be in V1 under the broader "integrity for code" banner? No implementation supports this right now, but I know it will definitely improve the guarantees a web application can provide.
>  • The spec doesn't really help an application developer figure out how to fall back to safer (say, non-cdn) resource when the SRI checks fail. 
> As usual, all the spec editors would look forward to feedback.
> 
> cheers
> #team-sri ;)

Hope this helps,


--
Mark Nottingham    mnot@akamai.com    https://www.mnot.net/

Received on Friday, 13 March 2015 06:19:16 UTC