CORS integration

[annevk]

I think we'd have to be extremely careful if we didn't require CORS (and given that most new things require CORS anyway it's not clear it's worth the hassle). And if we require CORS we need to consider whether the user agent can poke through the lack of Access-Control-Expose-Headers for these new response headers or not.

[mikewest]

I don't think anything in this proposal changes the CORS requirement; that really does seem mandatory for signatures and hashes alike.

I don't think it's necessary that we expose those headers, but I can see an argument that unless the headers are exposed, there's some information leakage based on the key used for signing (e.g. the contents of Signature-Input)? Is that what you're concerned about here, or have I missed your point?

[annevk]

Good. There was a suggestion at TPAC that it might not be needed when signatures are involved (by folks from Google) which surprised me.

As for exposing headers, I think ideally user agents would be able to use https://fetch.spec.whatwg.org/#cors-safelisted-response-header-name deep in the networking subsystem to identify which headers to share with their caller. If we poke holes in that by using response headers not in that list for internal purposes we end up making such a system more involved to deploy and less robust overall.

Not sure if there's an actual leak or not. Perhaps if the server was not expecting the browser to make use of headers that are not part of the safelist, which kinda is the desirable model.

[mikewest]

Good. There was a suggestion at TPAC that it might not be needed when signatures are involved (by folks from Google) which surprised me.

@ddworken might have additional context (or a different opinion?) here, but it seems necessary to me, and that's how the proposal is currently written.

If we poke holes in that by using response headers not in that list for internal purposes we end up making such a system more involved to deploy and less robust overall.

Assuming we run with #16, would you suggest adding Signature, Signature-Input, and *-Digest to the safelist? That doesn't initially seem unreasonable to me, and could clarify the ways in which delivering those headers might impact response handling.

[annevk]

Either we add them to the safelist or we require them to be specified by ...-Expose-Headers.

[mikewest]

Ok, thanks!

I'll add a monkey-patch to the doc once we work out what which headers we're planning to rely upon and evaluate their content. I know I'm not familiar enough yet with Signature and Signature-Input to judge risk. Assuming no surprises, I'd prefer adding them to the safelist, but we can evaluate that together later.

[ddworken]

Good. There was a suggestion at TPAC that it might not be needed when signatures are involved (by folks from Google) which surprised me.

@ddworken might have additional context (or a different opinion?) here, but it seems necessary to me, and that's how the proposal is currently written.

So I think the idea here was that it might not be necessary since signature-based SRI wouldn't provide any visibility into the contents of the response (unlike hash-based SRI, which allows probing against specific hash values). Though I do tend to agree that it is better to just keep the CORS requirement to avoid the complexity/risk here.

[estark37]

For posterity, I understood the argument against CORS requirement to be that the developer would have to add a header to the resource to serve the signature, and adding that header could be interpreted as opt-in for some information about the resource to be obtainable cross-origin. But I agree that it's not worth the complexity.

[mikewest]

The monkey-patch spec doesn't make any changes to SRI's general CORS requirement, and notes it as part of https://wicg.github.io/signature-based-sri/#privacy. With that in mind, I'll close this out. Thanks, all!

[annevk]

Are you sure? What about the new headers?

[mikewest]

You're right, I forgot about that aspect of the thread. Reopening this. :) I'll try to flesh out the Fetch integration today and ask you to take a closer look at it.

[mikewest]

I didn't get to it yesterday, but just pushed an update that aims to sketch out the fetch integration in a little more detail. I'd appreciate feedback on https://wicg.github.io/signature-based-sri/#monkey-patch-fetch.

For the header exposure, I sketched things in the doc as adding these headers to the safelist. That doesn't seem unreasonable to me, but I did notice that other security checks (CORP, CSP, etc) all just sift through inner response headers. Following that precedent would be equally simple. WDYT, @annevk?

[annevk]

Let's see:

1. It seems better to operate on the internal header list and not safelist them unconditionally.
2. "Perform client-initiated integrity checks given request and response, then run processBodyError and abort these steps." Seems wrong. I suspect you meant to check a return value?
3. What about new request headers? Is that no longer part of the proposal?

[mikewest]

Thanks!

1. SG, I can make that adjustment.
2. Yes. That seems like a mistake. :)
3. Fiddling with request headers in Public keys in request headers #21, which you just responded to. Haven't turned that into spec language yet, will do so once we figure out what the behavior is that we actually want.

[mikewest]

1. SG, I can make that adjustment.

6e6abb7

2. Yes. That seems like a mistake. :)

50629bd

3. Fiddling with request headers in Public keys in request headers #21, which you just responded to. Haven't turned that into spec language yet, will do so once we figure out what the behavior is that we actually want.

I think I'd close this issue out (this time for real), and carry on with the discussion around adding request headers in #21. That will certainly require some additional discussion and drafting, but I think it's separable from the discussion in this issue. Skimming back through the thread, I think I've actually addressed everything we talked about here. If I missed something, do let me know. Otherwise I'll close this out tomorrow.