Re: Proposal: Signatures in SRI.

On Thu, Jun 1, 2017 at 11:42 AM, Martin Thomson <martin.thomson@gmail.com>
wrote:

> I think that signatures solve some of the concerns I've been seeing
> with SRI deployment, the biggest one being that you need to know what
> the content is before you can link to it.  This would add a layer of
> indirection, allowing you to identify a signer.
>

Right. I think it has real deployment advantages, especially for
first-party resources (your own code), and quasi-first-party resources
(colleagues with whom you have direct integration points).

sleevi@ and agl@ note that the usefulness for truly third-party resources
is limited, because key management is hard. It would be nice to ensure that
`https://apis.google.com/js/platform.js` is signed by Google, for instance,
but hard-coding a public key into a million websites that embed that
resource would make key rotation prohibitive, leading to some risk of key
pinning suicide, similar to the risks that appear with HPKP.

I threw out a proposal a while back that would address a fairly
> significant shortcoming of SRI: an inability to progressively process
> content.  It's a little more complicated than your proposal, but has
> the advantage of providing integrity over partial resources.  It also
> degenerates neatly to what you propose here.
>
> It's badly rotten, since I stopped maintaining it (time, wherefore art
> thou?), but I hope that you can at least get a taste:
> https://tools.ietf.org/html/draft-thomson-http-miser


https://tools.ietf.org/html/draft-thomson-http-mice, is, I think, the link
you were looking for.


> That also suggests an enhancement for integrity more generally.
>

I think it's a reasonable one, pretty much in line with what agl@ was
proposing a million years ago. We never ran with his proposal because folks
were concentrating on scripts and style (which are processed atomicly), and
the complexity of streaming was hard to justify.


> On your work:
> One major limitation of using ed25519 is that you can't incrementally
> calculate the signature; you should at a minimum consider the
> pre-hashed variant if you intend for this to be universally
> applicable.  The draft above would be trivial to get to work with
> ed25519.
>

I don't know enough in this space to have an informed opinion about the
options. CCing agl@. :)

Should this identify multiple signers?  This isn't quite pinning, but
> with long cache lifetimes, it could lead to similar sorts of lock-in.
>

Yes. I imagine this would work just like hashes today:
`integrity="ed25519-A ed25519-B"` would specify two public keys which would
be accepted for the given resource.


>
> On 1 June 2017 at 19:13, Mike West <mkwst@google.com> wrote:
> > TL;DR: I'd appreciate feedback on a proposal for a small, signature-based
> > extension to SRI and CSP.
> >
> > In talking to some folks internally at Google, we've found some use cases
> > for SRI in combination with CSP for some applications that the security
> team
> > is particularly interested in locking down. Prototypes of this combined
> > mechanism work the way they expect, but turning those prototypes into
> > production will be quite difficult, given the dependencies on shared code
> > written by several distinct teams and some additional requirements for
> > out-of-band delivery that aren't directly relevant to this proposal.
> >
> > Signatures seem like they would provide some of the same benefits, with
> real
> > deployment advantages. It seems like these advantages might be
> applicable to
> > other folks' projects as well, so I've written up a small explainer at
> > https://github.com/w3c/webappsec-subresource-integrity/blob/master/
> signature-based-restrictions-explainer.markdown
> > in the hopes of gauging interest. I'd appreciate y'all taking a look.
> >
> > We've talked about extending SRI with signatures a few times over the
> years,
> > and a few folks have put together different proposals for doing so (the
> > thread at https://github.com/w3c/webappsec/issues/449 contains a few
> > examples). Mine is a fairly narrow approach in comparison with some other
> > suggestions, which I hope is a feature. :)
> >
> > In broad strokes, I'd suggest the following:
> >
> > 1.  We add support for Ed25519 in `integrity` attributes and CSP source
> > expressions (e.g. `<script src="whatever.js" integrity='ed25519-[public
> > key]'>`).
> >
> > 2.  We add support for a server-side mechanism of delivering an Ed25519
> > signature along with a resource (e.g. a new `Signature:
> ed25519-[signature]`
> > header).
> >
> > 3.  We use the signature in the integrity attribute to verify the
> signature
> > in the header after receiving the resource (much as we do for hashes
> today).
> >
> > WDYT?
> >
> > -mike
>