Review of signature-based resource loading restrictions.

[mikewest]

Hello TAG!

I'm requesting a TAG review of:

• Name: Signature-based Resource Loading Restrictions
• Specification URL: [working on it, just an explainer for now]
• Explainer, Requirements Doc, or Example code: https://github.com/mikewest/signature-based-sri
• Primary contacts: @mikewest, @otherdaniel

Further details (optional):

Relevant time constraints or deadlines: Q4ish?

• I wrote the Self-Review Questionnare on Security and Privacy, but haven't applied it to this feature yet.
• I have reviewed the TAG's API Design Principles

You should also know that...

There's a discussion starting at https://lists.w3.org/Archives/Public/public-webappsec/2017Jun/0000.html that's quite relevant. @sleevi's comments at https://lists.w3.org/Archives/Public/public-webappsec/2017Jun/0004.html are particularly intriguing.

We'd prefer the TAG provide feedback as (please select one):

• open issues in our Github repo for each point of feedback
• open a single issue in our Github repo for the entire review
• leave review feedback as a comment in this issue and @-notify [github usernames]

[hadleybeeman]

Taken up at our Nice face-to-face.

Thanks for this, @mikewest! As always, you've spawned a deep and intensive conversation in the TAG. :)

We appreciate the use cases you're trying to address here and aren't aware of any other way of solving them. This seems like a sensible way to make it happen.

We've had some debate about the role of CDNs and how the trust model works... Specific questions will be forthcoming. But generally, we are in favour of this.

[triblondon]

@mikewest thanks for this, it's very interesting. Speaking as a CDN person, I'm anticipating that CDNs will want to provide this as a service to their customers, ie the customer shares their private key with us and we add the signature into the <script> tags, and add the Integrity header to the appropriate asset responses (or in the case of serving just the script asset, eg cdnjs, do just that half)

Anticipating that this might inspire a SHARINGPRIVATEKEYSWHATTHEHELL freakout, note that CDNs already terminate TLS on behalf of their customers, and also sometimes will validate their customers' user-authentication tokens as well. It seems not unreasonable to anticipate that they might naturally do this too.

This also prompted the thought that any middlebox that can see the content in the clear (eg a corporate proxy which has a root cert trusted by its employees machines) and is able to intercept both the page request and the asset request could modify both to ensure a valid match on the client.

We think this basically wraps up our TAG feedback, would like to express our undying adulation for your glorious specification abilities and thank you for flying TAG. Please come again.

[plinss]

Presumably multiple signature headers would be valid, should the provider want to sign with multiple private keys (during key rollover or such), or if a CDN wants to cross-sign with their own key. Is there potentially a use for multiple public keys on the consumer end? (so for example allowing signed content from one of multiple providers.)

I also have concerns about the distribution of the public keys, we have the general problem of MITM attackers fooling consumers into using the wrong key. I appreciate that this is trying to be a simple solution, but wonder if we're not going to have to go to a full certificate solution eventually anyway, and maybe we should just bite that off now.

[cynthia]

@triblondon There is no added value of having the CDN sign in your behalf, at the point everything can be injected/rewritten from the CDN this use case would probably be better covered by the CDNs simply issuing a new key pair for this functionality. The key doesn't have any authority or meaning to the end users, so there isn't much of a point in sharing the key.

[triblondon]

Oh, one other thought - is there any impact of the scout pattern of loading JavaScript libraries:
https://alexsexton.com/blog/2013/03/deploying-javascript-applications/

[mikewest]

@triblondon:

I'm anticipating that CDNs will want to provide this as a service to their customers

CDN-provided services are basically SRI's threat model. :) One goal is to ensure that a page loads the bits that its owner uploaded to the CDN, unmodified (https://w3c.github.io/webappsec-subresource-integrity/#resource-integrity). It's actually meant to reduce the necessity to hand over the keys to your kingdom to the CDN.

The use cases I'm personally interested in involve a creator holding a private key offline, using it at build-time to sign resources, then taking it offline again until the next build. Signing content dynamically on the server seems to substantially reduce the guarantees the signature provides. I'm sure there are valid use cases for that kind of setup, but, again, it's not the use case we're targeting.

I look forward to chatting with y'all about it tomorrow. :)

[cynthia]

Signing content dynamically on the server seems to substantially reduce the guarantees the signature provides. I'm sure there are valid use cases for that kind of setup, but, again, it's not the use case we're targeting.

I believe if you have a CI that automates building and deploying to a staging server that is a exact replica of the production, and you take the built package straight to production if everything works in staging, you would want your CI server to sign it for simplified deployment. (given that the CI server has decent policies blocking private key access, this probably is not too likely to happen in the real world though.)

[otherdaniel]

@triblondon @cynthia I think you all are actually agreeing, but just wanted to add that a CDN could certainly do its job without knowledge of the private key. However, knowing the private key would allow a 'value add' CDN that e.g. also minifies, compresses, assembles, or elsehow prepares resources on behalf of a client. The proposed spec enables either use case.

The uses cases can even be mixed within the page, on a resource-by-resource basis. (E.g., CDN provides and holds the key for certain standard libraries, like the most up-to-date jQuery; while the page owner holds the key for the app logic.)

Basically, the last thing that is meant to legitimately modify the sub-resource data needs to hold the key. The spec has no opinion on who that should be.

That said, the only-page-owner-holds-the-key use case is certainly an important one.