search

WICG / signature-based-sri

Signature-based Resource Loading Restrictions
https://wicg.github.io/signature-based-sri/
Other
23 stars 3 forks source link

Signatures and hashes #19

Open yoavweiss opened 1 month ago

yoavweiss commented 1 month ago

Part of the discussion in #5 touched on the use cases for signatures vs. hashes.

The spec already talks about signatures ensuring provenance rather than content, but it'd be great to emphasize that signatures and hashes are not an either/or proposition.

The use-cases, as I see them: 1) If you're deploying specific script versions that you audited, you can use hashes to ensure the script wasn't tampered with at rest or during delivery. 1) If you're deploying specific script versions that you didn't audit, but trust their provenance, signatures can help you ensure that the script you downloaded is the one authored by the trusted party. Theoretically, that could be done on the server side and replaced by hashes when sent to the browser (but end-to-end signatures are easier to deploy) 1) You may be deploying evergreen scripts from a party you trust. There signatures are the only deployable way to ensure you that the scripts you're running are indeed authored by that party. Hash reporting can be a nice supplement to that, and enable you to retroactively validate with that party that no unexpected scripts signed by it are in use.

I'm not sure if there's actually a use case for both hashes and signatures, but maybe it's a variant of (2) that enables you to ensure that scripts from the trusted party aren't exchangeable after a certain point in time (where the hashes are calculated).

mikewest commented 1 month ago

Would you be interested in suggesting some use case text that we could add to "deployment considerations" or similar? The bullets you've laid out seem like a reasonable dichotomy to me.

Tangentially, I think 2 is also useful as a way of explaining packaging constraints like those that are being explored in https://github.com/WICG/isolated-web-apps/. Constraining scripts to those that are contained within a package can certainly be done by URL, but could also be done through a manifest of specified hashes. Similarly, the signing constraints on IWA packages could be reasonably expressed through the signature-based integrity proposal.

ddworken commented 1 month ago

I'll say it isn't entirely clear to me why one would want to enforce signature validation and pin a hash. It seems like that is equivalent to just pinning the hash, and validating the signature once, so I don't necessarily see why someone would do both. But I'm also not opposed to supporting this if other people see utility in this.

mikewest commented 1 month ago

I don't think there's value in most cases. But I'm absolutely certain that developers will specify both, and we have three choices: 1. Explode. 2. Enforce only one. 3. Enforce both.

2 means we need to make decisions about which kind of assertion to ignore. I'm not confident in deciding one way or the other at the moment. That, plus consistency with hashes and CSP enforcement lead me to 3, but that's a weakly-held position.

ddworken commented 1 month ago

I will say that option 2 does seem potentially reasonable since I think we could argue that pinning to a hash is stronger than pinning to a signature. So we'd just define getPrioritizedHashFunction as returning hashes over signatures.

But no strong opinions from me here, so if others prefer option 3, then that SGTM.

mikewest commented 1 month ago

In your auditor example from #20, is it really the case that we could reasonably ignore the request to validate the signature if the developer provided a hash? If that use case matters, it seems to be an argument for 3 not 2 (or 1, which I guess we both agree isn't the right option).

ddworken commented 1 month ago

That is a good point. :) Consider me leaning towards option 3 as the solution then.