Concerns (non-exhaustive):

• There are three use cases:
  • Non-HTTP distribution of Web content in places with bad/expensive connectivity in a way that verifiably ties to Web origin.
    • This use case isn't of world-wide interest (if you have tolerably fast and affordable networking, you are not going to bother with SD card or P2P transfer of Web apps even if you want to install them for offline use) and depends on comprehensible UI. While it would be good of vendors to address concerns that don't have world-wide appeal, such features have a difficult time getting significant UI real estate. Does this use case have UI buy-in at Google (the spec writer's affiliation) to make this use case realistic on the UI side?
  • Snapshot sharing without need to authenticate.
    • The spec itself mentions prior art here but dismisses it as non-interoperable. There's an xkcd for that. I'd like to see a much better explanation why interop for this use case would be achieved this time.
  • CDN verifiably speaking for a different origin.
    • Considering how far SRI goes on the topic of CDN verifiability and in a backward-compatible way (albeit without the ability to override origin for resources that don't operate with the authority of the origin referring to them), I have doubts that sites would choose to use this backward-incompatible feature. That is, it's not at all clear that the value provided by this feature would outweigh the risk of breakage with non-evergreen browsers that don't have this feature or the complexity of implementing things two ways to accommodate browsers that have this features and browsers that don't.
    • It isn't explained why packaging (as opposed to additional HTTP-level metadata) is the right solution for this.
• The spec is layered on top of CBOR, whose error handling story is antithetical to what the Web needs. (CBOR says anything goes but experience shows that well-defined error handling is the way to go on the Web.) The spec tries to impose some error handling requirements on CBOR, which means that you have to use a special-purpose CBOR processor limiting the benefit of layering on top of an existing spec.

FWIW, today I was asked about this by Yoav and a few Googlers.

Just noting the use of web packaging and AMP (blog post). We should evaluate what this means exactly and how web packaging addresses concerns around AMP.

This isn't a complete answer to @hsivonen's concerns, but I figured I'd point you to the up-to-date proposals before you re-review anything:

https://wicg.github.io/webpackage/draft-yasskin-http-origin-signed-responses.html is additional HTTP-level metadata to receive exchanges without talking to the origin server. It's the piece that we think is most immediately useful for AMP. It proposes a way for browsers to opt into CDNs pushing cross-CDN content, although @yoavweiss suggested a second way that I haven't analyzed or written up yet.

WICG/webpackage#98 is the start of the MHTML replacement, and the PR lists a couple ways that it improves on MHTML.

https://tools.ietf.org/html/draft-yasskin-webpackage-use-cases-00 has a more complete list of use cases, and was published in August.

See also @ekr's comment at #53 (comment)

Can someone kindly provide a link to the feedback @ekr referenced in #53?

@marcoscaceres Seems to be https://lists.w3.org/Archives/Public/ietf-http-wg/2018JanMar/0071.html

I'm finding myself a bit confused about which standards body this document seems to think it's targeted at. The link above is to a WICG repo but it's clearly an IETF draft.

There are several pieces: signed exchanges are aimed at the IETF; bundles are either aimed at the IETF or the WICG depending on conversations at IETF101; and the specification about how browsers load both of those, expose them to service workers, etc., will definitely go through the WICG. The whole thing is in a WICG repository because at the beginning it wasn't clear that I should bring signed exchanges through the IETF.

On the question of venue, it is pretty clear to me that addressing the architectural questions this work raises is something that both the IETF and W3C might have input on. I would not be happy unless both bodies agree that this is worthwhile.

I'm happy that this is going to the IETF. The question of what this does to HTTP is one that they need to address. That's necessary, but not sufficient. Even if the IETF agreed that this is a reasonable solution, the W3C might have grounds to object. We know that the TAG has already made a statement about one of the use cases that this enables; I expect them to have more to say.

Personally, I think that this is potentially very harmful, and it's not clear what would be required to address that concern. The way that this is set up suggests a range of use cases, but if just one of those has the potential to do significant damage to the ecosystem, we need to address that harm.

We should mark this harmful until we can be convinced otherwise.

I found the last paragraph of @ekr's post quite convincing in terms of showing that this is problematic since it changes what our security indicators mean in fundamental ways.

On the flip side, I think it's pretty important for a bunch of things:

• packaging is important for the effort to merge IDPF work into W3C and have an ePub successor that's based on Web Technology, although it's possible that effort is stumbling in other areas
• relieving some of the problems with AMP (as documented in the TAG finding on distributed and syndicated content and in the letter about Google AMP) in the ways described in the recent blog post
• solving various longstanding use cases related to archiving of web content and sharing of those archives

It's not clear to me what the path forward is; does any approach to packaging necessarily have this problem, or are there ways to avoid them? Does avoiding them require a new state for our security UI?

If you don't couple packaging with distributing content from a different authority it seems you could have packaging sans signing as a new kind of delivery mechanism; that might be enough for 1 and 3 of your list, but not 2 I suspect.

@annevk Yes, and that's the bundling spec that's separated out from the signed exchange spec.

My problem here is primarily with origin substitution. I'm actually fine with signing and offline I suggested a beefed up version of SRI-caching to @jyasskin as an alternative to this. I think the primary question at hand is whether there is a standalone mechanism where the client gets content displayed as origin X without any direct contact at all with X.

To @ekr's point the introduction to draft-yasskin-http-origin-signed-responses-02 clearly states that "When signed by a certificate ([RFC5280]) that’s trusted for an origin, an exchange can be treated as authoritative for that origin, even if it was transferred over a connection that isn’t authoritative (Section 9.1 of [RFC7230]) for that origin." Using signed HTTP exchanges to enhance the security of accessing a resource or verifying its authenticity seems like a good thing; but it seems positively harmful to use signed HTTP exchanges as a replacement for the longstanding web security model (e.g., RFC 6454 as Ted Hardie points out at https://lists.w3.org/Archives/Public/ietf-http-wg/2018JanMar/0079.html). I suggest that we let the discussion on the HTTP WG list play out further, and see how @jyasskin modifies his I-D in response to ongoing feedback.

We, Chrome team, would like to re-open Mozilla's standards position on Signed Exchanges given the updates to the specifications (https://tools.ietf.org/html/draft-yasskin-http-origin-signed-responses-05 and https://wicg.github.io/webpackage/loading.html) that have happened since the position was established.

Mozilla's current documented objections are:

1. "The ability for an origin to act on behalf of another without a client ever contacting the authoritative server is worrisome."
2. "As is the removal of a guarantee of confidentiality from the web security model (the host serving the web package has access to plain text)."

We are struggling with objection (1) because it doesn't describe any concrete harm caused by the change, especially since the authoritative server's content has plenty of opportunity to contact its server after the content loads. We haven’t heard more details on the thread where that concern was originally expressed.

We believe that Objection (2) isn’t a significant change from the status quo when considering more of the stack than just TLS, as described in https://lists.w3.org/Archives/Public/ietf-http-wg/2018JanMar/0089.html and https://wicg.github.io/webpackage/draft-yasskin-http-origin-signed-responses.html#privacy-considerations.

EKR also suggested an SRI-based solution, which I tried to write up in https://jyasskin.github.io/sideloaded-exchanges/draft-yasskin-httpbis-sideloaded-exchanges.html. We haven’t heard any feedback on that draft yet.

It’s unclear if our attempts at understanding or resolving the concerns are missing the point or are otherwise inappropriate, or if this is an issue of finding the time or a good person to review.

We acknowledge three important reductions in security relative to TLS, which we've tried to mitigate, and for which we’d love your help, both for evaluating the mitigations and improving them.

1. It's possible to replay a personalized response from an attacker to a victim, as now described in https://wicg.github.io/webpackage/draft-yasskin-http-origin-signed-responses.html#seccons-over-signing. That section gives signing systems some advice to try to prevent those problems, and clients block "stateful" headers to prevent cookie-based attacks.
2. An attacker can send a signed exchange that includes a recently-fixed mistake. This could be either an exploitable bug, which the attacker then exploits, or incorrect information for the victim to read. Purge mechanisms WICG/webpackage#376 discusses a way to mitigate the second, and if picking a particular choice improves Mozilla's opinion on the spec as a whole, that's likely to sway the decision.
3. Mis-issued certificates and stolen private keys are easier for an attacker to use and harder for a victim site to notice, similar to the issues described in draft-bishop-httpbis-origin-fed-up. Define a CAA parameter governing CanSignHttpExchanges cert issuance. WICG/webpackage#377 improves the situation for mis-issued certificates, but not all the way back to TLS. I'm looking for a way to improve detection of stolen keys that retains the surveillance-resistance offered by the current design. For browsers that don't care about surveillance, Purge mechanisms WICG/webpackage#376 could solve this.

We are looking forward to your response.

Hi @jyasskin, just acknowledging your request here. I'm working on getting you an answer. Understand that this is not a very high priority for us, and there is a lot of complexity. It might take us a while to get back to you.

Has @hsivonen's objection been addressed? Specifically the one about layering on top of CBOR, which has undefined anything-goes error handling. Even though I suspect it's not anyone's primary objection, this seems like a serious future interop hazard that could be fixed (if it hasn't been already).

@othermaciej I've approached @hsivonen's objection by sending patches to the next version of CBOR, which you can find at https://cbor-wg.github.io/CBORbis/draft-ietf-cbor-7049bis.html. We're much closer to "good" error handling there, in that the web packaging specs can say "if the CBOR is not valid, return a network error", and have that mean the right thing, but I wouldn't yet bet that we're all the way there. CDDL also has some issues along these lines.

Here is our updated position paper, which reaffirms our position: https://docs.google.com/document/d/1ha00dSGKmjoEh2mRiG8FIA5sJ1KihTuZe-AXX1r8P-8/edit?usp=sharing

This is based on the current state of the documents. We understand that this work continues to progress. Importantly, we hope to get more information from the upcoming ESCAPE workshop.

Also worth noting the version of the above position paper that was submitted for the ESCAPE workshop. (Also PDF rather than Google Docs.)

Is there any update on the Mozilla Position on Signed HTTP Exchanges? I think there was some progress in the discussion at IETF during the one year .
And also we are planning to introduce an extension to Signed HTTP Exchanges to support prefetching subresource Signed HTTP Exchanges of non-AMP sites. I think this can mitigate the concern about “the structural changes to site architecture" written in the position paper.

@horo-t, we hope Mozilla will not cave in to Google's attack on the open web, but thank you for asking.