Re: Signature-based SRI and CDNs

Hey Mark!

On Thu, Nov 9, 2017 at 1:38 AM, Mark Nottingham <mnot@mnot.net> wrote:

> Reading the minutes <https://www.w3.org/2017/11/07-webappsec-minutes.html#
> item04>, I see there was some question about what CDNs thought about
> signature-based SRI.
>
> As a person familiar with CDNs, I think it's safe to say this is *very*
> interesting -- generally, anything that gives Web developers more
> confidence about serving bits over a CDN is a good thing for them.
>
> I especially like the proposal to allow a signature to be communicated in
> a response header; that avoids the need to modify content.
>
> A couple of random thoughts:
>
> 1) The case for associating a public key with third-party content is
> relatively straightforward. It's much more difficult to establish a key for
> an entire host (see: pinning problems), but it would be very valuable for
> the increasingly-common case of an entire origin being delegated to a CDN.
>
> 2) The hard part about signatures for HTTP messages has always been
> picking which headers to sign, and canonicalising them. Header rewriting by
> intermediaries is less of a concern with TLS, but you still have the CDN
> itself to contend with, as well as any user-side software that's being
> "helpful." Content-Type seems like a good start, and as pointed out, Date
> is probably a good contender (although interactions with caching would need
> to be carefully considered).
>
> 3) One of the motivators for the design of encrypted content encoding <
> http://httpwg.org/specs/rfc8188.html> was random access to the payload,
> as well as partial content responses. It'd be cool if the design here could
> accommodate that (although doing that might make it more verbose / involved
> than desired for this use case -- although if you're doing Date header
> signing, it's already getting pretty involved). E.g., see <
> https://www.ietf.org/archive/id/draft-thomson-http-mice-02.txt>.
>
> From a HTTP WG standpoint -- we've been nosing around this space for a
> while, and I suspect there'd be interest and support for doing something in
> this area from folks there. If you want review / feedback, I'd be happy to
> circulate it.
>

I'd be happy for you to circulate it in that WG. There's certainly some
conceptual overlap, and getting more eyes onto the problem is probably
reasonable.

I see this breaking down pretty cleanly into two pieces:

1.  Some mechanism that allows a page to make a client-side assertion that
a resource or set of resources must be signed in a certain way before
execution/display. In https://github.com/mikewest/signature-based-sri,
that's the `integrity` attribute (and we discussed an extension of the
`require-sri-for`
CSP directive
<https://w3c.github.io/webappsec-subresource-integrity/#require-sri-for> at
TPAC).

2.  Some mechanism that allows a resource to make an assertion about its
own authenticity, that the client-side assertion can rest upon. In
https://github.com/mikewest/signature-based-sri, that's the `Integrity`
header (though it would need to also assert the public key in order to be a
self-contained authentication mechanism).

The first piece seems pretty straightforward as an extension of the
existing SRI mechanism. The second piece can be arbitrarily complex
depending on the properties we'd actually like the signature to embody. The
current proposal is very simple: sign the body (and maybe some additional
headers, as we've discussed elsewhere), and be done with it. That doesn't
support range requests, and doesn't support streaming validation, which
limits the use cases. Now, as it turns out, those use cases are pretty
useful, and I'm excited about getting _something_ out the door for folks to
experiment with to see if the deployment story we're telling ourselves is
accurate. If so, it might really be worthwhile to extend into something
more complicated.

In the working group meeting last week, there didn't seem to be a ton of
enthusiasm for tackling the complexity of the streaming case. From your
perspective inside a CDN, is that kind of integrity validation something
you think your customers would be interested in? Is it a problem we ought
to be prioritizing more than we are?

-mike