Re: SRI and signatures

(After writing this response, I wonder belatedly whether we should be
having this conversation on the HTTP WG list. :) )

On Mon, Dec 18, 2017 at 7:27 AM, Jeffrey Yasskin <jyasskin@google.com>
wrote:

> 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 believe that the `allResponseHeaders` flag forces all headers to be
signed for the certificate-based use case. I do think that's overkill for
the use cases we're trying to address with SRI (and, really, seems like
overkill for the web packaging use cases as well...), so we'd want to dial
it back a bit. That said, I'm a bit wary of having too much flexibility in
the approach. If there are specific attacks we care about, I wonder if it
might be reasonable to lock down a subset of meaningful headers as a
defense, and leave it at that.

I think we also disagree about the value of signing the resource's URL
(discussed briefly in B.2
<https://wicg.github.io/webpackage/draft-yasskin-http-origin-signed-responses.html#rfc.appendix.B.2>),
especially given the staging/production deployment distinctions we've
talked about before.


> 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?
>

FWIW, the internal use cases I know about were much more concerned about
rollback attacks (which you discuss in B.3.2
<https://wicg.github.io/webpackage/draft-yasskin-http-origin-signed-responses.html#rfc.appendix.B.3.2>)
than resource swaps. The latter would certainly be a bigger deal if a
server decided to sign arbitrary responses that might contain user
generated data, in which case, signing the `Content-Type` header would make
a lot of sense. Along those lines, we should probably take the opportunity
to enforce strict MIME type checks on signed resources, regardless of the
presence of a `nosniff` header.


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

Let's say "Something like this will be available behind a flag in Chrome
sometime in Q1", and hope we hit it. :)

(Note that the earlier `Integrity` header sketched out in
https://github.com/mikewest/signature-based-sri#the-proposal is behind a
flag in Chrome now, if you'd like to play with that. I don't think the
client-side assertion mechanism will change much, so your feedback on that
piece would indeed be useful!)

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
>>>
>>
>>