search

WICG / signature-based-sri

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

Multiple signature support #20

Closed ddworken closed 22 hours ago

ddworken commented 1 day ago

One of the issues raised in the monkeypatch spec is the question of whether it is useful to support validating multiple SRI checks against the same resource, and what semantics we'd want to support here. From the spec:

With known algorithms, we can adjust the prioritization model to return a set of the strongest content-based and signature-based algorithms specified in a given element. This would enable developers to specify both a hash and signature expectation for a resource, ensuring both that known resources load, and that they’re accepted by a trusted party.

Supporting both signatures and hashes is being discussed in #19. But let's discuss the question of supporting multiple signatures here.

ddworken commented 1 day ago

In my personal opinion, checking both a hash value and a signature value doesn't seem like it would be too useful since pinning a hash pins an exact version of the resource, such that checking a signature doesn't seem too useful.

What does seem potentially useful is supporting multiple signatures. There are two possible use cases for this:

  1. Specifying two public keys, and accepting the resource if it is signed with either key. This could be useful to support an extremely basic form of key rotation where a client can accept both an old and a new key.
  2. Specifying two public keys, and accepting the resource if it is signed with both keys. This could be useful to enable only executing a script if it has a signature proving it comes from a specified authority (e.g. Google Analytics) and a separate signature proving that it was independently audited (e.g. by an independent security firm).

I'm curious if other people see the utility in these two use cases, and how to balance this? We could of course add a way of specifying something like ed25519-[pubKey1] && ed25519-[pubKey2] so that users can specify which behavior they want. But that does add complexity.

My personal opinion is that the simplest thing to do might be to just not support multiple SRI checks, and defer this complexity until a later evolution of the proposal.

mikewest commented 1 day ago

I see value in 1 (which is how the spec currently defines the feature). It allows clients and servers to shift from one key to another without needing to do so in lockstep. Servers start with key A, announce they're shifting to key B, clients specify A and B, servers specify A and B, clients remove A, servers remove A. Requiring a jump from A to B without the intermediate steps seems likely to cause breakage.

Is your 2 a requirement folks have today? My intuition is that it isn't, but I'm not familiar enough with the ways regulatory requirements in this area are evolving. @yoavweiss and/or @igrigorik might also have thoughts from Shopify's position. If this is something we're confident we'll need, then I think it's reasonable to come up with ways to allow developers to express some kind of "required" signature vs "optional" signature. If it's not something we need today, it seems reasonable to defer.

WDYT?

(As an aside, I'd also note that your 2 shows a use case for using both hashes and signatures together: "I want exactly resource X, but I want my auditor to have signed it.")

ddworken commented 1 day ago

I see value in 1 (which is how the spec currently defines the feature). It allows clients and servers to shift from one key to another without needing to do so in lockstep. Servers start with key A, announce they're shifting to key B, clients specify A and B, servers specify A and B, clients remove A, servers remove A. Requiring a jump from A to B without the intermediate steps seems likely to cause breakage.

I do agree with that as a potential use case for 1, but I'm personally not sure that it is the best solution for key rotation. The tricky bit is that this would only allow key rotation once all clients have been updated to specify key A and key B, which for things like Google Analytics will never practically happen (since there are so many clients). This makes me think that if we want a (simple) key rotation solution, #21 is probably the better solution.

Is your 2 a requirement folks have today? My intuition is that it isn't, but I'm not familiar enough with the ways regulatory requirements in this area are evolving. @yoavweiss and/or @igrigorik might also have thoughts from Shopify's position. If this is something we're confident we'll need, then I think it's reasonable to come up with ways to allow developers to express some kind of "required" signature vs "optional" signature. If it's not something we need today, it seems reasonable to defer.

I'm not familiar with any requirement here. Though I'm also curious for Shopify/other feedback on this.

igrigorik commented 1 day ago
  1. Specifying two public keys, and accepting the resource if it is signed with both keys.

This ("both keys") has not come up in any of our explorations at Shopify, so far at least. For 1 ("either key"), I can see benefits as described. I'd focus on 1 to start.

ddworken commented 1 day ago
  1. Specifying two public keys, and accepting the resource if it is signed with both keys.

This ("both keys") has not come up in any of our explorations at Shopify, so far at least. For 1 ("either key"), I can see benefits as described. I'd focus on 1 to start.

Got it, that makes sense to me. This is enough of a reason that I am inclined to start with 1 ("either key") as the right option here. And if in the future people do see utility in supporting 2 ("both keys") then we could always add that as a future enhancement.

mikewest commented 22 hours ago

Great. I filed #23 to capture the suggestion for the future, and I'll close this out as it matches what's currently in the proposal.