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

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