Intent to Experiment: Signature-based Resource Loading Restrictions

[Daniel Vogelheim]

Contact emails

voge...@chromium.org, mk...@chromium.org

Spec

https://github.com/w3c/webappsec-subresource-integrity/blob/master/signature-based-restrictions-explainer.markdown

Summary

Extend Subresource Integrity attributes to also recognize (certain forms of) digital signatures.

Link to "Intent to Implement" blink-dev discussion

https://groups.google.com/a/chromium.org/d/msg/blink-dev/mm0MvKSS61g/iNfwM8l-BAAJ

Goals for experimentation

The motivation for the feature is to make Subresource Integrity (SRI) easier to deploy. The goal of the origin trial is to get some sites that do not presently deploy SRI to try out this newer feature, to validate that it would work sufficiently well in practice and that the deployment effort for them is reasonable. Their feedback should determine which changes are needed to work towards a launch.

Experimental timeline

The experiment should be enabled during two milestones. We are targeting M66 + M67.

Given that support of this feature potentially requires a lot of work on part of the participating sites, we might want an extension of the experiment duration if participating sites signal they need more time. I'm not sure of the proper process for this. I assume I'll have to ask again on this thread?

Any risk when the experiment finishes?

We don't think so. This situation was thankfully anticipated when SRI was specified: SRI is spec'ed so that unknown "digest" prefixes are ignored. Hence, adding a new SRI "digest" type to an existing page should have no effect once the trial runs out (or on older versions of Chrome, or on other browsers that would erroneously get a page with the signature-prefix delivered).

Ongoing technical constraints

None.

Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)?

Yes.

Link to entry on the feature dashboard

https://www.chromestatus.com/feature/5713333428682752

[Mike West]

On Mon, Jan 29, 2018 at 12:46 PM, 'Daniel Vogelheim' via blink-dev <blin...@chromium.org> wrote:

Contact emails

voge...@chromium.org, mk...@chromium.org

Spec

https://github.com/w3c/webappsec-subresource-integrity/blob/master/signature-based-restrictions-explainer.markdown

Summary

Extend Subresource Integrity attributes to also recognize (certain forms of) digital signatures.

Link to "Intent to Implement" blink-dev discussion

https://groups.google.com/a/chromium.org/d/msg/blink-dev/mm0MvKSS61g/iNfwM8l-BAAJ

Goals for experimentation

The motivation for the feature is to make Subresource Integrity (SRI) easier to deploy. The goal of the origin trial is to get some sites that do not presently deploy SRI to try out this newer feature, to validate that it would work sufficiently well in practice and that the deployment effort for them is reasonable. Their feedback should determine which changes are needed to work towards a launch.

One more thing to note is that this proposal for signature-based SRI vaguely looks like the intent to implement origin-signed HTTP exchanges that went out a ~week ago. If we squint enough, there might be a reasonable amount of overlap (and indeed, the `ed25519Key` bits of the spec Jeffrey's working on anticipates a potential merger). That said, the two proposals do have different characteristics and goals, and it's not clear that the restrictions folks think we ought to place on origin-signed HTTP exchanges (signing the whole URL, for instance) apply to SRI's threat model.

This experiment aims to get developer experience and feedback on the simplest thing that could possibly work for signed resources to see whether it actually addresses the deployment challenges we've seen with digest-based SRI in the past. If the feedback proves that hypothesis, we'll continue the conversation with the web packaging folks to make sure we don't step on each other's toes and that we have a reasonable story for developers who want to verify resource signatures one way or another.

 

Experimental timeline

The experiment should be enabled during two milestones. We are targeting M66 + M67.

Given that support of this feature potentially requires a lot of work on part of the participating sites, we might want an extension of the experiment duration if participating sites signal they need more time. I'm not sure of the proper process for this. I assume I'll have to ask again on this thread?

Any risk when the experiment finishes?

We don't think so. This situation was thankfully anticipated when SRI was specified: SRI is spec'ed so that unknown "digest" prefixes are ignored. Hence, adding a new SRI "digest" type to an existing page should have no effect once the trial runs out (or on older versions of Chrome, or on other browsers that would erroneously get a page with the signature-prefix delivered).

Ongoing technical constraints

None.

Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)?

Yes.

Link to entry on the feature dashboard

https://www.chromestatus.com/feature/5713333428682752

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CALG6KPPoQznFUbwvwh2yS63xotz%2BmjwrG9hXV8OT07SZtWXCvA%40mail.gmail.com.

[Harald Alvestrand]

back in the mists of time, we had the "shttp" scheme for signed resources. https://tools.ietf.org/html/rfc2660 (1999) gives the details.

It was totally wiped off the field by HTTPS, to the degree that few people seem to remember it ever existed.

Perhaps it's wise to make sure what we propose now solves the problems that killed that one, or at least gives a story of why that one died and this one will survive?

(Disclaimer: I do NOT know why it failed. EKR's still around to be asked.)

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAKXHy%3Dfs4V2o0Yfc-maQUhDAGKA_0DXnrCKVQxc%2BJHewUinLBQ%40mail.gmail.com.

[Daniel Vogelheim]

Hi Harald,

On Mon, Jan 29, 2018 at 2:48 PM, Harald Alvestrand <h...@google.com> wrote:

back in the mists of time, we had the "shttp" scheme for signed resources. https://tools.ietf.org/html/rfc2660 (1999) gives the details.

It was totally wiped off the field by HTTPS, to the degree that few people seem to remember it ever existed.

Perhaps it's wise to make sure what we propose now solves the problems that killed that one, or at least gives a story of why that one died and this one will survive?

Thanks for the feedback. I mostly disagree, though: The RFC 2660 you reference is substantially more complex than our proposal (multiple encryption modes; public signatures w/ X.509 certificates. etc). Given that our main motivation is making things easier to deploy, those are pretty much anti-features. In many ways, the main achievement of the spec I'm implementing here is that it it's simple (to implement; to understand; hopefully also simple to deploy). It accomplishes that by addressing some fairly narrow use cases. Widening that, without validation of the additional use cases, is risky.

There's some hope for your case, though: The rfc 2660 sounds like it has vaguely similar goals to origin signed responses (intent). As Mike said, we are exploring merging our proposal with that one. A reason for doing the origin trial now (and in the current form) is that we hope this gives us feedback on what aspects to keep and what needs fixing. This is the kind of information you can only get from actually attempting to deploy it.

[Harald Alvestrand]

This sounds like you think "simple to deploy" is the distinguishing feature between this proposal and RFC 2660 - I hope you're right!

[Yoav Weiss]

Overall I'm supportive of addressing this use-case. 

I know it's not yet an intent to ship, but I feel this intent would benefit from a few extra things:

* Indication of support from other browser vendors. The intent to implement stated support from Mozilla, but it might be better to open an official "request for position" on https://github.com/mozilla/standards-positions/issues. Would also be good to know what other vendors are thinking about it.

* TAG review - If you haven't started that process yet, it might be better to do so sooner rather than later (I had features blocked from shipping because the last-minute TAG review made us realize we need to change them. Not fun)

IMO, these are not blockers, but would be good to kick off.

On Mon, Jan 29, 2018 at 12:46 PM 'Daniel Vogelheim' via blink-dev <blin...@chromium.org> wrote:

Contact emails

voge...@chromium.org, mk...@chromium.org

Spec

https://github.com/w3c/webappsec-subresource-integrity/blob/master/signature-based-restrictions-explainer.markdown

Is there a normative spec explaining what it is that you intend to experiment with? The explainer is great, but it leaves a few questions unanswered, in particular about the implemented delivery mechanism for the signature itself.

If such a spec doesn't exist yet, can you make it explicit here which delivery mechanism was implemented?

 

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

[Mike West]

Hi, Yoav!

On Thu, Feb 1, 2018 at 9:18 AM, Yoav Weiss <yo...@yoav.ws> wrote:

Overall I'm supportive of addressing this use-case. 

I know it's not yet an intent to ship, but I feel this intent would benefit from a few extra things:

* Indication of support from other browser vendors. The intent to implement stated support from Mozilla, but it might be better to open an official "request for position" on https://github.com/mozilla/standards-positions/issues. Would also be good to know what other vendors are thinking about it.

The generally positive feelings we talked about in the intent to implement were explicitly linked, and we got some additional feedback at TPAC last year which was equally encouraging.

That said, explicit feedback would be better than random mailing list posts and hallway conversations. I didn't realize Mozilla was accepting requests, and I think we'd be happy to put up an issue. Perhaps we should add that to our process? (+rbyers@)

 

* TAG review - If you haven't started that process yet, it might be better to do so sooner rather than later (I had features blocked from shipping because the last-minute TAG review made us realize we need to change them. Not fun)

https://github.com/w3ctag/design-reviews/issues/186

 

IMO, these are not blockers, but would be good to kick off.

On Mon, Jan 29, 2018 at 12:46 PM 'Daniel Vogelheim' via blink-dev <blin...@chromium.org> wrote:

Contact emails

voge...@chromium.org, mk...@chromium.org

Spec

https://github.com/w3c/webappsec-subresource-integrity/blob/master/signature-based-restrictions-explainer.markdown

Is there a normative spec explaining what it is that you intend to experiment with? The explainer is great, but it leaves a few questions unanswered, in particular about the implemented delivery mechanism for the signature itself.

If such a spec doesn't exist yet, can you make it explicit here which delivery mechanism was implemented?

 This experiment will run with the `Integrity` header we've waved our hands at in https://github.com/w3c/webappsec-subresource-integrity/blob/master/signature-based-restrictions-explainer.markdown#the-proposal and in the Ed25519 tests in https://github.com/w3c/web-platform-tests/tree/master/subresource-integrity/. The main reason we don't have a more normative document written up is the aforementioned discussion we're having with the Web Packaging folks. If we end up piggybacking on their header, we won't need one of our own. Assuming that doesn't compromise too much on either side, it seems like the best outcome.

For clarity, the goal of this experiment is to learn about deployment challenges with public/private keys in general. To that end, we've done the simplest thing that can possibly work, and aim to iterate from there in cooperation with other projects. :)

-mike

[Yoav Weiss]

This all sounds great! :)

LGTM1

[Mike West]

On Thu, Feb 1, 2018 at 9:36 AM, Yoav Weiss <yo...@yoav.ws> wrote:

This all sounds great! :)

LGTM1

On Thu, Feb 1, 2018 at 9:31 AM Mike West <mk...@chromium.org> wrote:

Hi, Yoav!

On Thu, Feb 1, 2018 at 9:18 AM, Yoav Weiss <yo...@yoav.ws> wrote:

Overall I'm supportive of addressing this use-case. 

I know it's not yet an intent to ship, but I feel this intent would benefit from a few extra things:

* Indication of support from other browser vendors. The intent to implement stated support from Mozilla, but it might be better to open an official "request for position" on https://github.com/mozilla/standards-positions/issues. Would also be good to know what other vendors are thinking about it.

The generally positive feelings we talked about in the intent to implement were explicitly linked, and we got some additional feedback at TPAC last year which was equally encouraging.

That said, explicit feedback would be better than random mailing list posts and hallway conversations. I didn't realize Mozilla was accepting requests, and I think we'd be happy to put up an issue. Perhaps we should add that to our process? (+rbyers@)

https://github.com/mozilla/standards-positions/issues/54