Re: Proposal: Signatures in SRI.

+1 to all of Mike's points. I think this can be tremendously useful for a
lot of scenarios and, for Dropbox, I can assert that we will likely deploy
this for the full-1p case; SRI-hash is pretty painful to use for us (and I
imagine Google too). While in theory it shouldn't be, in practice adding
signatures is a lot easier. As I envision it, we should support a header
that (at a high level) says "make sure all loaded scripts are signed by a
key".

cheers
Dev


On 2 June 2017 at 06:19, Mike West <mkwst@google.com> wrote:

> Thanks, Ryan! I appreciate the detailed response, and I agree with some of
> the critique. :)
>
> I think we agree that scenarios exist in which it would be nice to make
> meaningful assertions about the content loaded into a page. I think we also
> agree that SRI's current digest-based mechanism deals with many use cases
> in a reasonable way. I think we even agree on the risks that
> signature-based mechanisms present if applied blindly to certain use cases.
> I think we disagree about the value that a signature-based system provides
> that balances against those risks; I'll try to outline the way I'm looking
> at this question in the discussion below.
>
> On Thu, Jun 1, 2017 at 4:07 PM, Ryan Sleevi <sleevi@google.com> wrote:
>
>> Perhaps incomplete, but my proposed set of categories to consider are:
>>
>
> I think the categorization you've proposed is pretty reasonable, but I'd
> note that lots of sites will fall into more than one of these categories.
> They'll have some components they control completely, they'll have some
> components controlled by colleagues, and they'll load resources of various
> kinds from third-party servers. It's probably clear, but just to be
> explicit: the decision about when a given form of SRI is appropriate is
> totally possible to make on a case-by-case basis.
>
> I'd also note that because of shared components, the notion of first- and
> third-party is relative. When `example.com` embeds a widget from `api.com`,
> that widget might well include more resources. `example.com` can't
> reasonably make assertions about them a priori, but the widget script from `
> api.com` probably could.
>
> - Full 1P can use SRI-Hash, because there's a central publication
>> mechanism in which all of the SRI hashes can be computed/known, and thus
>> injected as appropriate.
>>
>
> Full 1P can also use SRI-Sig, because there's a central publication
> mechanism in which all of the SRI public keys are known, and thus injected
> as appropriate. In fact, there are practical advantages to doing so, as in
> most cases the same public key can be used. As `<script integrity='[key]'>`
> will remain stable for every embedding page, sweeping intermediate cache
> invalidation can usually be avoided, whereas `<script integrity='[hash]'>`
> would require rebuilding the world every time any integrity-checked
> resource changed. This stability in the face of regular updates is pretty
> valuable, despite the challenges you note below.
>
> I'd also note that the nature of the assertion made by a signature is
> different than that made by a hash: the latter requires foreknowledge of
> the content, while the former evaluates provenance. That latter assertion
> seems like a valuable primitive to add to the platform, and would enable
> some interesting things in the future. For instance, I think would be
> practically impossible for even "Full 1P" origins to deploy an
> Orhttps://mail.google.com/mail/u/0/#inboxigin Policy
> <https://wicg.github.io/origin-policy/> that set a baseline CSP listing
> hashes of each individual script the origin might wish to use on any page
> (if only for mundane performance reasons, as such a list would be
> constantly changing). Deploying a baseline CSP that restricted an origin to
> a small set of signing keys, on the other hand, might well be practical.
>
> - Versioned 3P can use SRI-Hash, because the dependency graph of 3P
>> resources is known at time of 1P publication.
>>
>
> As above, SRI-Sig could be useful even in Versioned 3P scenarios because
> of the cascading side-effects of hash changes. Consider things like ES6
> modules, which import scripts (which themselves import scripts (which
> themselves import scripts (and so on))). Changing a leaf node would alter
> its hash, which would require an update to its parent to encode the new
> hash, which would require an update to _its_ parent, etc. Signatures seem
> like they would ease this churn.
>
>
>> Quasi 1P still has to maintain a centralized republication mechanism
>> (e.g. what Full 1P has) in order to handle key rollover events. A Quasi 1P
>> entity that doesn't is just setting themselves up for breakage in the event
>> of a key rollover event, the inability to publish (in the event of a key
>> loss), or the loss of security (in the event of a key compromise). Two of
>> these breakages directly affect users (the greatest constituent) for
>> reasons beyond their or the UAs control - that is, it's a footgun. The
>> third undermines the security guarantees, and thus isn't particularly
>> compelling for the UA.
>>
>> For Quasi 1P, I would assert that having the 1P have the capability to do
>> centralized publication is a net-good for their deployment, and the
>> experience of users. And while I realize that's telling site operators what
>> to do, it's also recognizing that SRI-Sig is not going to solve their
>> problem.
>>
>
> I think I agree with you that anyone relying on signatures for validation
> needs to be able to deal with the inevitability of compromise or loss.
> Ideally, folks using signatures would set up systems which allowed for
> regular rotation to keep that joint well-oiled.
>
>
>> Rolling 3P is just building an ecosystem ripe for massive user disruption
>> and the eventual disabling of SRI-Sig because of that. If you imagine a
>> situation like some ad or analytics vendor publishing their key for
>> consuming 1P, then any time they update that key (rotation, loss,
>> compromise), all of those 1P become broken, which means the user experience
>> is broken, which means the user agent is, while properly observing the site
>> authors intent, breaking the Web for users. It too is a giant footgun.
>>
>
> I agree that this proposal isn't going to help massively shared libraries
> with rolling updates (e.g. `https://connect.facebook.net/en_US/sdk.js`
> <https://connect.facebook.net/en_US/sdk.js> or `
> https://platform.twitter.com/widgets.js`
> <https://platform.twitter.com/widgets.js>), unless we dive into the
> cleverness you rejected, which I'm not terribly interested in doing. As
> noted above, however, it might be a good fit for the resources that script
> expects to include. The embedder itself couldn't hard-code a key for those
> resources, but the script could. For example, if a developer decides to
> embed a Tweet, `widgets.js` will render it inline; it would be expensive to
> include hashes for every resource, but a key might be practical.
>
> To me, it seems like SRI-Sig's "use case" is to support SRI for the case
>> of 'rolling updates', without requiring awareness of what those updated
>> resources are. This does match the deployment reality of the Web - that 1P
>> entities are often in the "Quasi 1P" scenario without centralized
>> coordination/publishing (and I believe that is Mike's intended use case),
>> and that most of the 3P resources - things like analytics and ads - are
>> equally on 'rolling updates' without centralized coordination.
>>
>
> I would hesitate to reject ads as a use case entirely. I can imagine
> signature-based restrictions being enforced on embedded contexts
> <https://w3c.github.io/webappsec-csp/embedded/> as an additional defense
> against malvertising. Since ads are unknown before page load, building up a
> set of a priori valid hashes would be difficult, but you could certainly
> imagine DoubleClick's frame selecting an ad, and then ensuring that only
> signed resources load. The footgun risk seems significantly lower in this
> scenario, as ads are short-lived by nature.
>
> *shrug* I see some value in adding this primitive. It seems to increase
> developers' ability to practically distribute assertions about the content
> they intend to load, and do so in a way that's both straightforward and
> simple.
>
> -mike
>
> P.S. As an aside, I'll briefly touch on a much more narrow (possibly
> Google-only) use-case that the stability of signatures enables: Google's
> security team would like to lock down some particularly high-risk internal
> web pages by enforcing SRI through CSP. Moreover, they're interested in
> doing so out-of-band of the page itself. Until Origin Policy
> <https://wicg.github.io/origin-policy/> ships, they're planning on doing
> so by force-installing an extension that ensures a policy is applied to
> every page. They can do so today with hashes, but that would be quite
> brittle in deployment, as folks would need to have the right version of the
> extension installed at all times. Signatures significantly reduce that
> complexity, similar to the origin policy discussion above.
>