Signed Exchanges

[jyasskin]

I'm requesting a TAG review of:

• Name: Signed Exchanges
• Specification URL: https://tools.ietf.org/html/draft-yasskin-http-origin-signed-responses
• Explainer, Requirements Doc, or Example code: https://github.com/WICG/webpackage/blob/master/explainer.md
• Tests: None yet.
• Primary contacts: @jyasskin

Further details (optional):

• Relevant time constraints or deadlines: We're hoping to do a Chrome Origin Trial by Oct/Nov 2018.
• [ ] I have read and not yet filled out the Self-Review Questionnare on Security and Privacy. The primary "yes"es are:
  • "Does this specification enable new script execution/loading mechanisms?" (since it allows a resource on one origin to provide script for another origin that signed it) and
  • "Does this specification allow downgrading default security characteristics?" (since signing an exchange allows an attacker to serve that exchange throughout its up-to-a-week lifetime, even if the server has fixed a bug since then).
  • The spec does have security and privacy considerations.
• [x] I have reviewed the TAG's API Design Principles, but for example feature detection isn't fully worked out, and none of the eventual Javascript APIs are designed yet.

You should also know that...

The IETF's HTTPWG is also reviewing the specification.

It's not clear whether I get better feedback by mentioning that, among the other listed use cases, this allows AMP to fix its URL problem (which causes some people to stop thinking beyond "AMP is bad"), or not (which causes some people to decide I'm trying to hide something), so please pretend I did whichever helps you think more about the details of the proposal.

We'd prefer the TAG provide feedback as (please select one):

• [x] open issues in our Github repo for each point of feedback
• [ ] open a single issue in our Github repo for the entire review
• [ ] leave review feedback as a comment in this issue and @-notify [github usernames]

[torgo]

Pending discussion at IETF in London where @slightlyoff will participate.

[torgo]

Discussed possibly needing a breakout on this Saturday pending @plinss review.

[slightlyoff]

Briefly discussed at today's F2F. @plinss had questions about the cert/key structure (separate cert issued by the CA rather than by the site and derived from the site's private key and TLS key info) and will read sections 4 and 5 to see if there are questions. May need more time to discuss with @jyasskin on Sat (TOK time, Friday PST).

There aren't other open questions from the TAG perspective; looking forward to hearing back about implementation experience.

[cynthia]

~should probably be touched on during the F2F extra time session for this review.~

(Not sure what I was trying to reference here, but was linked to a irrelevant issue)

[slightlyoff]

Per today's F2F, @plinss notes that the list of state-changing header feels in Section 4.1 doesn't currently include Public-Key-Pins, Strict-Transport-Security, or Expect-CT. Is that an oversight?

[triblondon]

In 3.2.1, the example uses a full URL in the request line and no Host header:

GET https://example.com/ HTTP/1.1
Accept: */*

HTTP/1.1 200
Content-Type: text/html
Digest: SHA-256=20addcf7368837f616d549f035bf6784ea6d4bf4817a3736cd2fc7a763897fe3
Signed-Headers: "content-type", "digest"

That seems like invalid HTTP/1.1 to me. Is there a rationale for that?

[plinss]

My primary concerns relate to increasing the trust relationship between the exchange signing certificate and the origin (beyond the PKI trust of the exchange signing certificate).

In particular: 1) is there (or should there be) an expectation (or restriction) that the same CA used to sign the origin's TLS certificate has signed the exchange signing certificate? 2) are the origin's CAA DNS records respected for issuing exchange signing certificates (or should there be a different CAA record type for exchange signing certificates)? 3) If the client has previously visited the origin, can they then use some cached information to cross-check the signed exchange, for example a Public-Key-Pin or TLSA record (or possibly a different mechanism to pin signed exchange keys)? 4) Is there an expectation that static key pins will apply to signed exchanges?

[triblondon]

Process note: We are posting individual review notes here and will invite @jyasskin to a call ahead of raising formal issues on the WICG repo as requested.

[slightlyoff]

There was one question brought up today about the processing model. If it's expected that requests in SIgned Exchanges trigger Service Worker onfetch events, it'd be good to understand when and how that works. This may require outlining a fuller processing model for signed exchanges in HTML, but for now it'd be great to see a discussion of this in the Explainer.

[plinss]

On a separate note, I'd like to see the ability to revoke certificates used for signed exchanges with fine granularity. The use case being where an origin wants to revoke a particular exchange, but not revoke other exchanges that may have been previously published. This would require different certificates to be used for individual signed exchanges.

Perhaps allowing an origin to obtain a CA-generated exchange signing certificate, and then use that certificate as an intermediate used to sign other self-issued certificates that are used to actually sign the individual exchanges.

[plinss]

@jyasskin are you available to join us for a call to discuss further? Potentially our 2018-04-24 telcon (0800 PDT, though we can accommodate other times if needed)

[jyasskin]

I'm available in general at 8am PDT, but I'll be on vacation on April 24th. April 17 or May 1 should work. BlinkOn is April 18-19 in case you want to get in specifically before or after that.

https://github.com/w3ctag/design-reviews/issues/235#issuecomment-379423243: Public-Key-Pins, Strict-Transport-Security, and Expect-CT don't look like they can be used for replay attacks (downgrade for DoS, maybe, but that's different from the reason we block cookies), so I think I was right to skip them, although it's definitely possible that I missed other headers that I should have included. The summary of "stateful header field" isn't exactly right, but I haven't been able to think of a better one: suggestions are welcome.

https://github.com/w3ctag/design-reviews/issues/235#issuecomment-379424440: Formatting my HTTP/1.1 wrong there is just a bug. I don't have automated tests for my RFC draft.

https://github.com/w3ctag/design-reviews/issues/235#issuecomment-379424835:

1. I don't see a way to enforce that the exchange-signing certificate is issued by the same CA as the origin's TLS certificate(s). These things are meant to be used offline without a connection to the TLS server.

2. I intend CAs to follow the same procedures when issuing an exchange-signing certificate as they follow when issuing a TLS certificate, including CAA. Where would you expect to find a statement to that effect?

3. Yes, previously discovered information about an origin should affect which certificates are accepted for signed exchanges.

4. Yes, static key pins should restrict exchange-signing certificates.

https://github.com/w3ctag/design-reviews/issues/235#issuecomment-379424926: I'm working on the bit of the explainer that describes the SW and HTTP cache integration. Expect this by Friday. The rough sketch is that prefetch should only go through the physical URL's SW, but a navigation has an effective redirect to the logical URL, at which point that load goes through the logical URL's SW, with probably an extra attribute on the event notifying it that the content has been pre-populated.

https://github.com/w3ctag/design-reviews/issues/235#issuecomment-379425103: Note that online revocation checks don't work in either the offline or privacy-preserving prefetch use cases. We're handling certificate revocation using stapled OCSP responses and content revocation using the maximum signature lifetime (7 days, the same as OCSP, for now). If you want to revoke a particular exchange without revoking other exchanges signed by the same certificate, update its validityUrl to remove the signature and stop posting new signatures there. Clients willing to take a round-trip will notice the missing signature at the validityUrl, but offline clients will have to wait for whatever expiration you picked for the signature.

[plinss]

I'm available in general at 8am PDT, but I'll be on vacation on April 24th. April 17 or May 1 should work. BlinkOn is April 18-19 in case you want to get in specifically before or after that.

Ok, I'm traveling on April 17, so let's shoot for May 1 then.

235 (comment): Public-Key-Pins, Strict-Transport-Security, and Expect-CT don't look like they can be used for replay attacks (downgrade for DoS, maybe, but that's different from the reason we block cookies), so I think I was right to skip them, although it's definitely possible that I missed other headers that I should have included. The summary of "stateful header field" isn't exactly right, but I haven't been able to think of a better one: suggestions are welcome.

Cool. We listed those because they do affect state that a browser keeps about the origin. But I'm happy to see them allowed. Presumably then a signed exchange could set Public-Key-Pins or Strict-Transport-Security for the origin should the client later visit directly (within the header expiration, of course).

235 (comment): Formatting my HTTP/1.1 wrong there is just a bug. I don't have automated tests for my RFC draft.

235 (comment):

I don't see a way to enforce that the exchange-signing certificate is issued by the same CA as the origin's TLS certificate(s). These things are meant to be used offline without a connection to the TLS server.

Understood that they have to work when completely offline, and if the recipient of the exchange is offline and has never interacted with the signing origin, then of course they have to rely solely on the content of the exchange. In my head I'm looking for ways to correlate signed exchanges with the origin when the client has previous interactions, since the exchange is using a different certificate than the origin's tls cert. A same CA restriction is probably not worth the trouble (and likely to cause CA lock-in/transition problems anyway).

I intend CAs to follow the same procedures when issuing an exchange-signing certificate as they follow when issuing a TLS certificate, including CAA. Where would you expect to find a statement to that effect?

A statement isn't necessarily necessary. Since it's a new use of a certificate I was just checking. I do wonder if there's value in having a different CAA record for exchange signing certificates, so a domain could opt-out, for example, or use a different CA.

Yes, previously discovered information about an origin should affect which certificates are accepted for signed exchanges.

Cool. So a previously discovered (and not expired) HPKP header should be used to validate the key used in a signed exchange? (for clients respecting HPKP)

Yes, static key pins should restrict exchange-signing certificates.

235 (comment): I'm working on the bit of the explainer that describes the SW and HTTP cache integration. Expect this by Friday. The rough sketch is that prefetch should only go through the physical URL's SW, but a navigation has an effective redirect to the logical URL, at which point that load goes through the logical URL's SW, with probably an extra attribute on the event notifying it that the content has been pre-populated.

235 (comment): Note that online revocation checks don't work in either the offline or privacy-preserving prefetch use cases. We're handling certificate revocation using stapled OCSP responses and content revocation using the maximum signature lifetime (7 days, the same as OCSP, for now). If you want to revoke a particular exchange without revoking other exchanges signed by the same certificate, update its validityUrl to remove the signature and stop posting new signatures there. Clients willing to take a round-trip will notice the missing signature at the validityUrl, but offline clients will have to wait for whatever expiration you picked for the signature.

Ok, I'll take another look at that.

[jyasskin]

Ack, sorry if you tried to discuss this today. Please send me the telecon info (or have @slightlyoff invite me) for the day you want me to dial in. I'm available any Tuesday in May.

[jyasskin]

https://github.com/WICG/webpackage/blob/master/explainer.md#signed-exchange-loading-sketch now sketches the SW and HTTP cache integration. Right now, I'm saying the inner response isn't cached, to avoid some complexity, but I'm hoping to revisit that once I've done a pass through bundles and some of the other security questions around signed exchanges are a little more answered.

[hadleybeeman]

Hello! I see that the HTTPWG was going to review this. What were their thoughts?

[jyasskin]

The HTTPbis presentation at IETF101 is at https://youtu.be/RaNy8HewRqM?t=1h25m22s, with discussion starting at https://youtu.be/RaNy8HewRqM?t=1h37m23s. There was also a "side meeting", with notes at https://mailarchive.ietf.org/arch/msg/art/pGwdfccdeLNaKUZKiGr1H42dFSo.

My memory is that @ekr is very concerned about the security properties, and he, @mnot, and @martinthomson are concerned about the possible centralizing effects of large sites being able to distribute content for smaller sites. Other folks at the IETF, mostly publishers, both then and at an un-noted side-meeting at IETF102 were excited about being able to distribute their content in new ways. We hope that the IAB/TAG workshop that's tentatively scheduled for late January will help us figure out what effects to expect from the change in distribution models.

[travisleithead]

Hey Jeff,

We reviewed the latest draft and explainer updates at today's F2F in Paris and are very happy with the progress and direction of the work. In particular, the proposed placement of Service Workers vs. SXG in the loading pipeline looks great and we're happy to see it. Looking forward to hearing how security review of this setup goes.

We were hoping to find more details about the validity-url. What happens if oa cert matches but the validity URL does not load? Does that fetch never happen?

Most of our open questions relate to Bundles, which we realize aren't in scope for this review. Specifically, we'd like to see:

• A discussion of how SXG and Bundles are handled when directly fetch()'d. We presume those will be different (an individual SXG yeilding the content, whereas a bundle might not unwrap the content)?
• An API for opening Bundles and dealing with their content; e.g. how can I populate a SW cache out of a few resources from a Bundle fetched over fetch()? We have a general interest in seeing the platform's encoders and decoders exposed to userspace to enable better layering.
  • PRegarding the last point, any plans to provide a CBOR encoding/decoding API as part of this work?

Overall we're excited that this work is moving forward quickly. Hoping to hear what you're able to learn from the Origin-Trial.

-Travis, Yves, Alex, and Peter

[nyaxt]

Thank you for the feedback!

We were hoping to find more details about the validity-url. What happens if oa cert matches but the validity URL does not load? Does that fetch never happen?

Short answer: If the signature is valid, the UA will load the content without fetching the validity URL. We expect only intermediates to fetch the validity-url, not UAs.

A UA could fetch the validity-url to get a live assurance that the signed data is current, but the current loading spec only discusses the UAs which do not do this. For those UAs without validity URL support, only the validity of the validity URL (whether they pass a URL parser && has a https scheme && is same-origin with the signed url) is checked and the resource hosted at the validity URL is not checked.

We have not yet specified how loading should work for the intermediates which support validity-urls. I just opened an issue https://github.com/WICG/webpackage/issues/324.

Regarding SXG/Bundle handling in fetch() and how the platform API should look for Bundles, we are still exploring how these should work. We will be sure to answer your questions in the upcoming loading spec.

-- @jyasskin, @nyaxt, @kinu

[slightlyoff]

This all makes sense to me! Thanks. In general we're happy with how this design hangs together and are grateful for your patience in the review process. Thanks for engaging with us!

Regarding the other questions we asked on fetch(), encoders/decoders, and API for bundles; where should we file that feedback?

[BigBlueHat]

@slightlyoff not sure you meant to close this given your last comment ends with a question. GitHub should really move those buttons farther apart. 😃

[jyasskin]

In general, please file feedback in https://github.com/WICG/webpackage.

To your specific questions,

• fetch() integration is specified precisely in https://wicg.github.io/webpackage/loading.html#monkeypatches. File bugs if that specification implies any behavior you don't like. :smiley:
• I believe CBOR and Bundle encoders and decoders should be out-of-scope for v1 of the spec. We should implement a Javascript library that encodes and decodes these things, and see how its users feel about its API before carving it into the platform.
• I think we can develop enough confidence in adding something simple like Cache.addBundle(Blob) in v1, but defining Bundles in the first place is a higher priority.