W3C home > Mailing lists > Public > public-webappsec@w3.org > December 2017

Re: SRI and signatures

From: Devdatta Akhawe <dev.akhawe@gmail.com>
Date: Sun, 17 Dec 2017 08:39:15 -0800
Message-ID: <CAPfop_38GpHt6+7M1Rne+jC-uTZifZ9RmcyRq6WBj3ssTVTJPg@mail.gmail.com>
To: Daniel Vogelheim <vogelheim@chromium.org>
Cc: public-webappsec@w3.org

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.


On 12 December 2017 at 08:44, Daniel Vogelheim <vogelheim@chromium.org>

> 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
Received on Sunday, 17 December 2017 16:39:59 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:55:02 UTC