Re: Proposal: Signatures in SRI.

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` or `
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.