Intent to Implement: Signature-based Resource Loading Restrictions

100 views
Skip to first unread message

Daniel Vogelheim

unread,
Aug 9, 2017, 5:53:28 AM8/9/17
to blink-dev

Contact emails

voge...@chromium.org, mk...@chromium.org



Spec

https://github.com/w3c/webappsec-subresource-integrity/blob/master/signature-based-restrictions-explainer.markdown



Summary

Extend Subresource Integrity attributes to also recognize (certain forms of) digital signatures.


Motivation

Subresource Integrity (SRI) can be used to guarantee that resources received (Javascript, CSS) are what the page author had intended and have not been modified in-flight, even when loaded from an untrusted source or transmitted over untrusted networks. The page author does so by including the hash code of the resource in the resource-ful element. This works well in all deployment scenarios where there's close coupling between the main page and included resources.


However, it's challenging to deploy SRI in situations where the content changes frequently or isn't known beforehand. Developers must ensure that the expected hash is updated in sequence with the resource, which is challenging (e.g. for code shared between diverse development teams in an organization). For these scenarios, it seems useful to provide developers with a mechanism to trust the entity that produced the resource. A signature provides a different kind of guarantee than SRI can provide today, as it verifies the provenance of a resource rather than its content. This addresses some of the original use cases for SRI while promising less fragility in the face of updates.



Interoperability and Compatibility Risk

Risk: Rather low. Subresource Integrity is spec'ed so that unknown "digest" prefixes are ignored. Hence, adding a new SRI "digest" type to an existing page will have no effect on other browsers (or previous versions of Chromium). Like-wise, should we one day decide to [remove|rename] this feature, pages using this feature will continue to operate just fine.


Support: The feature has been discussed in the webappsec group (here). Tentative support from Mozilla and web developers (Dropbox).



Ongoing technical constraints

None.

(The required crypto routines are already part of Chromium/Blink, which should make this a straightforward extension of the existing SRI implementation.)



Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)?

Yes.



Is this feature fully tested by web-platform-tests?

I plan on adding upstreamable web-platform-tests.



OWP launch tracking bug

https://crbug.com/753349


Link to entry on the feature dashboard

https://www.chromestatus.com/feature/5713333428682752



Requesting approval to ship?

No.

(Implemention will be behind a Blink feature flag, SignatureBasedIntegrity)

Dimitri Glazkov

unread,
Aug 9, 2017, 11:52:41 AM8/9/17
to Daniel Vogelheim, blink-dev
LGTM1

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CALG6KPPFe8ptaVNuaYa1x3iiG3MR%3DfXTVG3YYCD9Pi-5Gm5Nmw%40mail.gmail.com.
Reply all
Reply to author
Forward
0 new messages