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

Hey Mark

Thanks! Your comments are spot on. I have opened a task at
https://github.com/w3c/webappsec/issues/217 to keep track that we fix
all the issues you point out (If you are feeling generous, feel free
to send a pull request ;).

Couple of questions though:

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

I think we are trying to say that "UAs should have such a function,
even if it is just 'return a;'"". We definitely don't want to mandate
a priority list since UAs should have the flexibility to evolve this
as we learn more about hash functions. How do you suggest spec'ing
this?

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

While I will do a pass closer to LC to spot such issues, if you have
thoughts on lines that could be changed, feel free to point them out
here or on Github.

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

We are slowly leaning towards (in v1) insisting on CORS. So, will that
assuage your concerns?

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

I don't recall, but this is definitely vNext material.


cheers
Dev




>> 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 Wednesday, 18 March 2015 04:31:34 UTC