Intent to Implement: Origin-Signed HTTP Exchanges (Part of Web Packaging)

[Kinuko Yasuda]

Contact emails

Eng: kin...@chromium.org, kou...@chromium.org, ho...@chromium.org

PM: kenji...@chromium.org

Spec: jyas...@chromium.org

Explainer

No explainer specific to Origin-Signed HTTP Exchanges yet (Jeffrey will have one up soon).

In the meantime, see a sample of use cases for Origin-Signed HTTP exchanges and the broader context from the Web Packaging explainer (https://github.com/WICG/webpackage/blob/master/explainer.md).

Design doc/Spec

Spec:

https://wicg.github.io/webpackage/draft-yasskin-http-origin-signed-responses.html

(We will have additional spec(s) for the application/http-exchange+cbor format and its loading)

Design Doc:

https://docs.google.com/document/d/1zXEGCl3GI4JShJFkwq_7jsIcxJNjlPUgb0RW2Flqt-c

Related tag review links:

https://www.w3.org/2001/tag/doc/distributed-content/

https://github.com/w3ctag/packaging-on-the-web/blob/gh-pages/README.md

Note that the TAG has not specifically reviewed the current iteration of the proposal.

IETF DISPATCH WG feedback:

https://datatracker.ietf.org/doc/minutes-99-dispatch/

Summary

Support origin-signed HTTP Exchanges in Chrome’s loading pipeline, so that signed Web documents can be loaded and navigated as if they came from particular origins regardless of where they are actually served from.

Initially, we will only support signed exchanges wrapped in the application/http-exchange+cbor envelope format. Each application/http-exchange+cbor envelope will have single signed exchange.

Motivation

WebPackaging opens up various compelling use cases, including offline peer-to-peer webapp sharing, web publications, and integrity-preserving distribution of content from non-authoritative server. The HTTP working group recommended that this be split up into two layers: a way to sign individual request/response pairs, and a way to bundle several such exchanges. This Intent is for the first layer, which supports distribution and an improvement to how we attribute AMP content to the right origin.

Risks

Interoperability and Compatibility

High (early spec stages)

Edge: No public signals

Firefox: No public signals

Safari: Public skepticism: https://twitter.com/othermaciej/status/950997728275804160

Web developers: Multiple publishers, teams, projects and AMP are showing interest.

Security

The draft lists several security concerns, especially that this relaxes the on-path restriction for attackers with an illegitimate certificate, and that this allows attackers to use buggy code for a period after it's fixed on the real server. Thorough discussions with security experts are happening and we expect to have more of those as we make progress.

Ergonomics

This will often be used with prefetch and eventually HTTP/2 Push. The signed exchange format assumes its validator can initiate a fetch for the certificate, which may be difficult if the validator is inside the network layer.

Publisher serve a signed exchange by serving a normal response plus Signed-Headers and Signature headers.

Distributors can forward a signed exchange either by HTTP/2 Pushing it (not supported in our initial implementation) or by linking to an application/http-exchange+cbor resource.

Activation

We will provide a tool publishers can run to create the Signature header or the wrapped resource, using their TLS private key.

Debuggability

We will need (at least) following features integrated in DevTools:

• [P1] Network panel shows recursive prefetches for resources referred to from inside a prefetched signed HTTP exchange.

• [P2] Clicking a response holding a signed HTTP exchange should show the content of CBOR envelope, including the certificate, signature, and whether the signature is valid.

• (There could be possibly more)

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

Windows, Mac, Linux, Chrome OS and Android will be covered.

Android WebView is still TBD

Link to entry on the feature dashboard

https://www.chromestatus.com/features/5745285984681984

Requesting approval to ship?

No

[owe...@chromium.org]

I'm excited about Web Packaging, thanks for pushing this forwards! 

I believe it will enable a number of new use cases on the web. For example, I've recently been exploring P2P sharing of web content - an example use case would be sharing a document / game / video with a friend while offline, or receiving a copy of a metro map while offline underground in a metro.

[Yoav Weiss]

I'm super excited about this work, from multiple perspectives:

<cdn-person-hat>

This feature will enable CDNs to serve origin-signed content from origins that are not on their network (and which private keys they don't have). Origins signing their static resources would make those resources available to be cached anywhere, and sites that use those resources could download them over their own H2 connections, avoiding connection establishment and contention costs, without compromising on the resource's integrity.

That should result in significant performance wins when delivering such resources.

Caveat: I'd love to see a content negotiation mechanism that will enable edge servers to request a signed resource from the origin. I'll file an issue on the spec.

</cdn-person-hat>

<performance-person-hat>

Web packaging (not the Origin Signed part, but the packaging format part) can help us solve the problems we have around resource bundling.

Right now there's a clear tradeoff for bundling JS/CSS resources: Larger bundles provide improved compression ratios, but later execution, as the entire bundle must be downloaded before execution starts.

Web packaging can help us sidestep that dilemma and deliver all our (static, non-credentialed) resources in a single compressed bundle, that is processed in a streaming fashion. No tradeoffs!

Packaging also seems doubly important when we look at ES6 modules that have to be delivered in their own file. AFAIUI, current bundling processes work around that by smooshing multiple modules together as part of the bundling process. Would be great to avoid that need.

Finally, from a caching perspective, web packages are superior to bundles, as they can enable invalidation of specific resources, where today the entire bundle gets invalidated.

Aside: I was hoping we can fix these issues by extending the protocols and pushing compression to the h2 layer. Lack of excitement from the security community has since caused me to doubt it will become a reality in the near future.

</performance-person-hat>

<api-owner-hat>

The use-case as outlined by the AMP team seems like a win that will enable decentralizing content which aggregators provide to their users.

The current model where aggregated content (AMP, but also MIP, Baidu's variant) is often served from the aggregator's domain is not necessarily healthy for the Web's long-term success. I'll be glad to see that model go away, and this feature seems paramount to enabling that.

Other use-cases, such as offline sharing of PWAs also seem important and can potentially increase the reach of web apps in emerging markets.

At the same time, from an interoperability point of view, Safari's public skepticism and lack of support from other vendors is worrying. I hope that by the time this will get to Intent to Ship, we'll have a brighter outlook on that front.

</api-owner-hat>

All in all, I'm very happy to see this being worked on. I have some specific feedback on the design at the points where it touches on features I worked on, but I'll keep those details to design doc comments.

--
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.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/30cffa39-01cd-4140-b65e-d046cb161d4b%40chromium.org.