Re: CfC: Subresource Integrity (SRI) to Last Call?

I'm not particular tied to any syntax. I have never viewed the 'integrity'
attribute as a resource identifier (to the contrary, in the cases we're
dealing with, there is a separate resource identifier), so the ni:/// never
felt appropriate to me, and I've preferred the symmetry with CSP here. I
also don't feel too strongly, so if we want to have another conversation
about it, I'm definitely open to it. As Dev said, as well, we've also kept
the syntax explicitly open in case we want to use ni:/// or any other
syntax going forward.

On Wed, Apr 22, 2015 at 12:01 PM Austin William Wright <aaa@bzfx.net> wrote:

> Understood about implementations, which addresses my second concern.
>
> I severely doubt user agents will ever implement a new syntax if there's
> an old one, used by servers in the wild, that's of identical functionality
> for their intents and purposes. It seems unlikely even if a more compelling
> case for ni: for other parties presents itself in the future. Meanwhile,
> ni: has implementations too, just not in user agents. I just see it as an
> unfortunate state of affairs.
>
> I do see an IETF or similar document defining a new link-extension for
> Link: header purposes, and for more generic uses and supporting other media
> types (Atom, etc), but called something else (maybe "digest"). User agents
> and servers would both need to support two kinds of attributes in this case.
>
> While I haven't seen the specific rationale for changing to the CSP style,
> I suspect many of the concerns have since disappeared, like Content-Type
> handling. In my understanding, the implementations at this stage should be
> for prototyping, and behavioral and syntactical changes are still routine,
> even changes touching many more code paths than just token parsing. If
> there's anything I can do, like re-examining the draft and issuing a pull
> request, I'd be happy to make it.
>
> ~~~
>
> The possibility of a Link: link-extension reminds me of a concern with
> CSS, that it does not support generalized linking (with title, type, etc).
> It seems sort of odd that the stylesheet language of the Web doesn't
> support Web-style linking, right? It only has support for referencing
> network resources with URLs. (I would guess this has been brought up
> before, I can't find any discussion on it though. References would be
> wonderful!)
>
> If an issue is raised with the CSS WG, it should support these generalized
> link attributes too, preferably referencing RFC 5988 Web Linking. If we can
> specify title, type, hreflang, etc in a `link` element, why not in CSS?
> Those attributes make just as much sense in there too.
>
> This way, SRI could define an "integrity" link-extension and CSS and the
> HTTP Link: header would automatically support it.
>
> ~~~
>
> The first point was a suggestion for an entry in Security Concerns,
> addressing the possibility that a resource might have two meanings
> depending on its Content-Type, where one could be malicious.
>
> The entry would note that checking the hash by itself is not a guarantee
> of *behavior*, since there's other variables that affect this too,
> including media type, security policy, CSP headers, origin for same origin
> purposes, links (especially Link header for e.g. stylesheets, prefetch),
> and so on.
>
> I believe it would be accurate to describe this as "Hash is not
> necessarily homomorphic to behavior/interpretation" and servers should not
> assume they're making an assertion about anything except the resolved
> response entity-body; that this doesn't make assertions about HTTP headers,
> redirects, etc.
>
> Thanks,
>
> Austin.
>
>
> On Wed, Apr 22, 2015 at 8:18 AM, Devdatta Akhawe <dev.akhawe@gmail.com>
> wrote:
>
>> Hi Austin
>>
>> The simple truth is that there are already implementations that use the
>> new style. I am not sure that the concerns you raise are actually going to
>> be a problem, but I agree with you that they could be. This is
>>
> FWIW, it would not be difficult for Chrome to switch back to the ni:///
syntax, so I don't think we should make that a blocker on using it.

> exactly why the spec was modified to explicitly allow the possibility of
>> us changing syntax and introducing more formats (the spec mandates UAs to
>> ignore syntax they don't know about). You also pointed out some concerns
>> and made a PR that was pulled in IIRC.
>>
>> Do you have suggestions of what we could do beyond that? Changing
>> implementations and spec to use ni:// at this point is extremely unlikely.
>>
>> cheers
>> Dev
>>
>> On 21 April 2015 at 12:47, Austin William Wright <aaa@bzfx.net> wrote:
>>
>>> I've sort of skipped ahead to the 'call for implementations' part (but
>>> of course, don't let this stop breaking changes) with a Drupal module [1].
>>>
>>> Recent changes to the document seems to have been highly motivated by
>>> user agent concerns. I'm guessing there's been a number of implementation
>>> concerns where it was just easier to remove certain functionality
>>> altogether?
>>>
>>> First, I'm concerned that there's now no way to fix the media type of
>>> the response, since it's the case that two identical information resources
>>> can have completely different interpretations based on their media type. I
>>> would like to see the possibility of this attack noted in Security
>>> Considerations, and if this is addressable with e.g. CSP, a note on how to
>>> do that.
>>>
>>> Second, as described in my earlier email, I would still like to push to
>>> adopt an NI-compatible hash identifier. The "<alg>-<hash>" syntax seems
>>> just as arbitrary as "ni:///<alg>;<hash>", except the latter allows forward
>>> compatibility with ni: URIs. SRI has a great number of implications beyond
>>> those of CSP, and so I'm interested in the draft not painting itself into a
>>> corner. Specifically, SRI walks and quacks like a link attribute (like
>>> "rel", "title", "type", etc), and I see it being used in more general cases
>>> in the future, including for purely server-side uses.
>>>
>>> Tangential to the ni: URI issue are things like 'hard-coding' hash
>>> algorithms (instead of referring to e.g. the IANA registry), and use of a
>>> dash "-" to split the algorithm from the hash, instead of a more common
>>> separator character like a semicolon. I don't think these negatives are
>>> worth it just to share syntax with CSP, the use-cases are, in reality,
>>> largely orthogonal.
>>>
>>> Cheers,
>>>
>>> Austin.
>>>
>>> [1] <https://github.com/Acubed/drupal-sri>
>>> Actually I worked on this a while ago. It's sort of out of date as of
>>> now.
>>>
>>>
>>>
>>> On Mon, Apr 20, 2015 at 11:55 PM, Frederik Braun <fbraun@mozilla.com>
>>> wrote:
>>>
>>>> The remaining open issues[1] on GitHub are mostly editorial nits. The
>>>> technical parts should be well in place to advance to Last Call.
>>>>
>>>> I am aware of no fundamental controversies but would really like to get
>>>> some wider attention on the spec.
>>>>
>>>> The current editor's draft is at
>>>> <http://w3c.github.io/webappsec/specs/subresourceintegrity/>.
>>>>
>>>>
>>>> The CfC will end in a week, that is April 28th, 2015.
>>>>
>>>>
>>>>
>>>> [1]
>>>> <
>>>> https://github.com/w3c/webappsec/issues?q=is%3Aopen+is%3Aissue+label%3ASRI+milestone%3ASRI-v1-LC
>>>> >
>>>> and
>>>> <
>>>> https://github.com/w3c/webappsec/issues?q=is%3Aopen+is%3Aissue+label%3ASRI+no%3Amilestone
>>>> >
>>>>
>>>>
>>>
>>
>