Re: Proposal: Signatures in SRI.

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.

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

That also suggests an enhancement for integrity more generally.

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.

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

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

Received on Thursday, 1 June 2017 09:43:13 UTC