search

WICG / signature-based-sri

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

Integrity Signature Header is Under-Specified #2

Closed otherdaniel closed 1 day ago

otherdaniel commented 7 years ago

The Integrity: header is only introduced as:

Integrity: ed25519-[base64-encoded result of Ed25519(console.log("Hello, world!");)]

  1. It doesn't say anything about whether there can only be one or multiple values per header, or how multiple headers would be treated, 1a. it would likely be easiest if this were to have the same general format as the integrity attribute with multiple allowed valued, and multiple headers being treated the same as their concatenated values, 1b. not sure if comma separation of tokens should also be allowed, or whether that's a Chromium specific thing. 2, The prefix "ed25519-" is used to specify the key in the main resource, but used to specify the signature in the header. These should probably be different prefixes, as these are different things with different lengths.
mnot commented 7 years ago

+1.

Also, Integrity is a bad name for this; it doesn't describe what the header is. Something like Signature is more appropriate.

The tricky part of this is describing what is being signed; the body is a given, but headers need careful consideration. Content-Type is an obvious one here, but since so much policy is being put into headers these days, some amount of flexibility is probably going to be necessary.

jyasskin commented 7 years ago

@mnot I think it may be a mistake to allow signers to choose what subset of headers is signed. e.g. http://noxxi.de/research/breaking-dkim-on-purpose-and-by-chance.html#breaking shows how to break DKIM in practice because people made bad choices about what to sign and what unsigned content to trust.

We may need to have the Signature: header say what order to concatenate headers, but then we also need to say that any header not included is simply dropped.

Also see #5 for an argument to include the URL and maybe other request headers.

mnot commented 7 years ago

Canonicalisation is the big concern. Sometimes people don't have access to the exact bytes of their headers, sometimes implementations try to be "helpful", and sometimes middle boxes do things.

Also, the set of significant headers for signing can change both over use cases and time.

There probably needs to be a minimal set of headers, and the ability to add to it. C

mikewest commented 1 day ago

Closing this in favor of #16.