Re: SRI and signatures

https://wicg.github.io/webpackage/draft-yasskin-http-origin-signed-responses.html#signed-headers
currently lets the signer select which response headers are signed, but the
request URL is signed unconditionally. That's open to change as more folks
present use cases or attacks.

I'm surprised you'd be comfortable signing just the body. I assume you're
planning to use the same key for multiple resources: what makes you think
an attacker couldn't cause problems by swapping one out for another?

This Signature header isn't implemented by any UA yet.

Jeffrey

On Sun, Dec 17, 2017 at 8:45 AM Devdatta Akhawe <dev.akhawe@gmail.com>
wrote:

> Hi
>
> I like both approaches. If the other approach has more traction, I think
> that's fine. I do worry about signing headers though: in addition to the
> issues with CDN etc per your email, I also think it is different from how
> SRIv1 which only signs body. Is there a chance that the origin-signed HTTP
> responses could make signing headers optional (or do they do this already)?
>
> Are origin-signed HTTP responses implemented in any UA? That might be the
> easiest way to check if they work for/hinder any use cases.
>
> cheers
> Dev
>
>
> On 12 December 2017 at 08:44, Daniel Vogelheim <vogelheim@chromium.org>
> wrote:
>
>> Hi Dev, all,
>>
>> Thanks for looking into this!
>>
>> The IETF's HTTP group is currently looking at a related proposal in the
>> context of web packaging, which has a good bit of overlap with the SRI
>> proposal discussed here: Origin-signed HTTP Responses
>> <https://wicg.github.io/webpackage/draft-yasskin-http-origin-signed-responses.html> specifies
>> a (similar but different) way for HTTP responses to contain a digital
>> signature. This could either be based on a TLS certificate - which is the
>> main thrust of that proposal - but could also be an ed25519 key (unrelated
>> to the TLS certificate hierarchy), as it is in SRI explainer posted here.
>>
>> We'd prefer to avoid multiple incompatible signature schemes for HTTP
>> resources, and so we're looking into whether we can base our SRI ideas off
>> of this other work instead. Generally, that proposal should be quite
>> compatible with our ideas: Both make it a duty of the resource to supply
>> its integrity information in a new header. In their case, they then
>> serialize the exchange; in ours, we would require the integrity info either
>> from an integrity=.. attribute, or via a content security policy.
>>
>> From what I'm seeing, there are two main structural differences between
>> the signature-based-SRI explainer and the Origin-signed responses:
>>
>> - Origin-signed responses support multiple signature schemes. They
>> support ed25519 keys (so you can use ephemeral keys with whatever key
>> rotation scheme you see fit), but they also want to be able to tie their
>> signatures to a specific origin via the existing TLS public key
>> infrastructure.
>> - They also sign some of the headers. This makes a lot of sense in their
>> context (providing equivalence to a TLS connection in an offline package),
>> but I worry this would make live hard for SRI for CDNs or other complex
>> deployments, since then you need to guarantee that your CDN preserves
>> (certain) headers.
>>
>> I'm particularly interested in any feedback whether adopting this new
>> scheme would improve/hinder any specific use cases and if so, whether this
>> suggests any changes. Any comments?
>>
>>
>> Daniel
>>
>
>