Web Packaging
charter-ietf-wpack-01

[Ballot comment]
I agree with Ben Kaduk the goal of "Address[ing] the threat model of a website compromised after a user first uses the site." requires clarification.

[Ballot comment]
Thanks for addressing and clarifying my block points on any transport-related potential touch points! The charter seem fine to me now to move on. I think my old comments below are still valid though (for the record mainly).

One editorial comment: I find the chosen form of listing goals rather than writing text that describes the scope of the work not very reader-friendly (at least more the main/key goals). I think text instead of quite short bullet points would be more meaningful and would probably have avoided some of the discussion/confusion we had about this charter.

Further I agree with Ben that this part is not very clear and could be better scoped:
"Security and privacy properties of using authenticated bundles as close as
practical to TLS 1.3 transport of the same resources."

[Ballot block]
Thanks for all the discussion that happen on the charter so far, unfortunately there are still a few points that are not fully clear to me from a transport perspective:

1) It not clear to me how you plan to address low latency. I assume you don't want to optimise anything in the lower layers but it does sound a bit like it. Can you clarify this point?

2) I think "Being extensible and crypto agile" is a requirement we have for any protocol we design. Is there anything special here, or why is this listed?

3) I also don't really understand this point
"Specifying constraints on how clients load the formats without describing
specific loading algorithm to help achieve the above goals"
Can you further explain? I assume there are no transport implications here but as I'm not sure what is meant, I'd like to double-check!

4) Again here I'm not sure what is meant and I assume you don't plan for any transport protocol changes or extension but double-checking!
"Optimize transport of large numbers of small same-origin resources."
What does this mean? What's the solution you have in mind?

[Ballot block]
Thanks for all the discussion that happen on the document so far, unfortunately there are still a few point that are not fully clear to me from a transport perspective:

1) It not clear to me how you plan to address low latency. I assume you don't want to optimise anything in the lower layers but it does sound a bit like it. Can you clarify this point?

2) I think "Being extensible and crypto agile" is a requirement we have for any protocol we design. Is there anything special here, or why is this listed?

[Ballot comment]
One editorial comment: I find the chosen form of listing goals rather than writing text that describes the scope of the work not very reader-friendly (at least more the main/key goals). I think text instead of quite short bullet points would be more meaningful and would probably have avoided some of the discussion/confusion we had about this charter.

Further I agree with Ben that this part is not very clear and could be better scoped:
"Security and privacy properties of using authenticated bundles as close as
practical to TLS 1.3 transport of the same resources."

[Ballot block]
It looks like we've gotten some good discussion on the community feedback mentioned
in my previous Block, though we may still be waiting for a response on the intent of the
"Support books being published in the format" secondary goal.

I am not sure how appropriate it is to have milestones for "signing document"s given that
we say that WPACK will attempt to reuse work on HTTP signing from HTTPBIS.

I think there were some more s/signed/authenticated/ changes that were indicated but
not present in the 00-12.

[Ballot block]
It looks like we've gotten some good discussion on the community feedback mentioned
in my previous Block, though we may still be waiting for a response on the intent of the
"Support books being published in the format" secondary goal.

I am not sure how appropriate it is to have milestones for "signing document"s given that
we say that WPACK will attempt to reuse work on HTTP signing from HTTPBIS.

[Ballot comment]
It's not entirely clear to me whether "low latency to load a subresource" fits better
as a primary or secondary goal.

We say we'll try to have security and privacy properties "as close as practical to
TLS 1.3".  Do we have a sense for how much distance we are willing to accept
(vs. conceding that we cannot uphold our security and privacy requirements
and produce something that satisfies the  key goals) and still publish?

When we say that we will try to "address the threat model of a website compromised
after a user first uses the site", I'm not entirely clear on which properties we're trying
to preserve in the face of such threats.

Regarding the "automatic discovery" non-goal, does this preclude a way for a website
to indicate how to retrieve an offline-usable version of a resource when that resource
is being fetched "on-line"?

Are there other IETF WGs (in addition to W3C and WHATWG) that might have some
knowledge about security and privacy models for the web?

[Ballot comment]
I agree with Ben that the comments received just before and after the last telechat should be discussed on the mailing list before we approve this.

[Ballot block]
We've received some community feedback since the latest updates to the proposed
charter text, and I don't see any subsequent discussion to indicate that the concerns
have been properly understood and deemed to be unactionable.  (They clearly have
not been addressed, since no edits to the charter text have been made.)

[Ballot block]
  The WPACK working group will develop a specification for a web packaging
  format that efficiently bundles multiple HTTP representations. It will also
  specify a way to optionally sign these resources such that a user agent can
  trust that they came from their claimed web origins. Key goals for WPACK are:

A key feature of the modern web is that HTTPS is becoming almost
universal: HTTPS provides not just encryption for the content but also
integrity protection and source authentication, but we've had to put a
fair bit of effort in to get to where we are.  I'm not sure that we want
to leave ourselves with a new baseline of "unsigned" and another fair
bit of effort to get back to "most things have cryptographic
protection".  While I recognize that there are some use cases for WPACK
where the origin may not be cooperative and the entity creating or
distributing the packages needs to remain anonymous or pseudonymous, I
don't think that precludes signing the resources in some way.  What the
exact semantics of such signing would be are, of course, not clear yet,
but I'm reluctant to endorse a charter that describes the signing as
just "optional".

[Ballot block]
  The WPACK working group will develop a specification for a web packaging
  format that efficiently bundles multiple HTTP representations. It will also
  specify a way to optionally sign these resources such that a user agent can
  trust that they came from their claimed web origins. Key goals for WPACK are:

A key feature of the modern web is that HTTPS is becoming almost
universal: HTTPS provides not just encryption for the content but also
integrity protection and source authentication, but we've had to put a
fair bit of effort in to get to where we are.  I'm not sure that we want
to leave ourselves with a new baseline of "unsigned" and another fair
bit of effort to get back to "most things have cryptographic
protection".  While I recognize that there are some use cases for WPACK
where the origin may not be cooperative and the entity creating or
distributing the packages needs to remain anonymous or psedoymous, I
don't think that precludes signing the resources in some way.  What the
exact semantics of such signing would be are, of course, not clear yet,
but I'm reluctant to endorse a charter that describes the signing as
just "optional".

[Ballot block]
  The WPACK working group will develop a specification for a web packaging
  format that efficiently bundles multiple HTTP representations. It will also
  specify a way to optionally sign these resources such that a user agent can
  trust that they came from their claimed web origins. Key goals for WPACK are:

A key feature of the modern web is that HTTPS is becoming almost
universal: HTTPS provides not just encryption for the content but also
integrity protection and source authentication, but we've had to put a
fair bit of effort in to get to where we are.  I'm not sure that we want
to leave ourselves with a new baseline of "unsigned" and another fair
bit of effort to get back to "most things have cryptographic
protection".  While I recognize that there are some use cases for WPACK
where the origin may not be cooperative and the entity creating or
distributing the packages needs to remain anonymous or psedoymous, I
don't think that precludes signing the resources in some way.  What the
exact semantics of such signing would be are, of course, not clear yet,
but I'm reluctant to endorce a charter that describes the signing as
just "optional".

[Ballot comment]
  * The ability to create an unsigned snapshot of a web page without the
  cooperation of its publisher.

Similarly, perhaps this would be "without a signature from its
publisher".

  * Being extensible and crypto agile.

Generally good things, though I'm curious if there's a particular
direction(s) of extensibility in mind.

  * Support more-efficient signing of a single, possibly same-origin HTTP
  resource.

More efficient than what?


I am also confused about the "self-extracting executables" point that
others mentioned.

[Ballot comment]
Similar as Suresh, I'm uncertain how this goal would impact the format:

"Allow the format to be used in self-extracting executables."

Actually the list of goals seems to list a quite large variety of different aspects on various levels of depth. It not clear to me if all this needs to be in the charter. If there is agreement about what the group wants to do that good of course but (as the one mentioned above) if it's not clear how a goal would actually impact the technical work/format, it not fully clear to me why it is listed in the charter.

[Ballot block]
There is one topic that I think we should discuss before sending this charter for external
review, though I'm not sure I can express my concerns very clearly yet.  Basically, we've
been making great progress of late at getting the web to use HTTPS; this provides not just
encryption of content but also integrity protection and source authentication for website
data.  (I just learned today that by some metrics 80% of the web is HTTPS.)  The proposed
charter here has explicit goals of making unsigned packages, that lose the integrity protection
and source authentication we've been fighting hard for with traditional HTTPS.  Do we want
to endorse those goals without further caveats?

[Ballot comment]
This item seems oddly specific

"* Allow the format to be used in self-extracting executables."

but it is not clear to me that this is a property of the format. Can you clarify a bit what the format needs to do to meet this?

Like Adam, Alissa, and Barry I would love to see a bit more elucidation of the "avoid centralization" aspect of the charter.

[Ballot comment]
"* A low likelihood that the new format increases centralization or power
imbalances on the web. See discussion of this in
"

Unlike the other goals listed, it's hard to see how this is actionable. Will the WG make design decisions differently whether this is in the charter or not? If this working group were designing a system architecture or a protocol with an architecture that implied relationships prone to centralization would need to be created or strengthened for deployment purposes, perhaps this would be an appropriate goal. But the scope here is to specify a format that will be used in the context of the existing web with all of its existing centralization and power imbalances derived from the economic properties of the businesses operating within it. To me, stating this goal is sort of like saying we'll try not to throw kindling on a forest fire that is already propelled by gale force winds. We can say we'll do that, but what actually happens won't be determined by whether we do it or not.

[Ballot comment]
  * A low likelihood that the new format increases centralization or power
      imbalances on the web.

I don’t have much confidence that this can reasonably be achieved in reality, but I have no objection to having it listed as a goal.

  In particular, because
  something is in the initial document set (consisting of
    does not imply

I suggest that the complaint about this part could be best addressed by not listing the drafts in the charter and by saying it this way:

NEW
  In particular, because
  something is in an initial working group draft does not imply
END

[Ballot comment]
I have some questions.

Does there exist an easy way to resolve the clash between this primary and non-goal?
Primary goal:
* The ability to create an unsigned snapshot of a web page without the
cooperation of its publisher.

Non-goal:
* A way to distribute the private portions of a website. For example, WPACK
might define a way to distribute a messaging application but wouldn't
define a way to distribute individual messages without a direct connection to
the messaging application's origin server.

So the issue I wonder over, is that if I as a user decide to snapshot a web-page that contains some server-side dynamically generated resources. To my understanding that would result in that dynamically user specific generated content would be captured. How does this relate to the above non-goal. Or are these two different usages of the targeted solution. One to allow snap shoting what one actually provided, and another a configuration for distributing a part of a web-site?

The above thought lead to the question: Is it at all possible to prevent a user from sharing their private content if using this mechanism? Will the packager be able to determine what is private and what is not so that the user can select between a snapshot and sharing the general part of a web-site?

Next:

Relationship to Other WGs and SDOs

WPACK will work with the W3C and WHATWG to identify the existing security and
privacy models for the web, and to ensure those SDOs can define how this format
is used by web browsers.

Will calling WHATWG an SDO create any issues for the IETF? WhatWG is to my knowledge an Industry Forum.

[Ballot comment]
No objection to external review, but I think there are some issues we need to
see addressed prior to approval.


> * A low likelihood that the new format increases centralization or power
> imbalances on the web.

I'm glad to see this in the charter. I would really like to see this bullet
point expanded to more clearly cover the three different categories of
specific concerns described in section 4.1 of draft-iab-escape-report (or,
alternately, cite that document for further detail).

> Note that consensus is required both for changes to the current protocol
> mechanisms and retention of current mechanisms

I think this presumes a bit too much. Although the adoption of the initial
candidate documents may be highly likely, this text clearly implies that
their adoption is a fait accompli.

> In particular, because
> something is in the initial document set (consisting of
> draft-yasskin-wpack-use-cases, draft-yasskin-wpack-bundled-exchanges, and
> draft-yasskin-http-origin-signed-responses)

I also think we really need clearly-defined milestones here. Particularly,
seeing draft-yasskin-wpack-use-cases in the list of candidate documents,
I believe we need to clearly indicate whether the WG intends to publish
a use case document, especially in the context of the IESG statement at
https://ietf.org/about/groups/iesg/statements/support-documents/
If the intention *is* to publish the document, indicating that such
is the case (and why) will help during IESG review of such a document.

[Ballot comment]
Interesting work to be done. As I have some non-blocking comments/questions (see below), I have entered a 'no objection' but this is mostly a 'yes'.

Suggest to replace 'Three examples to" by 'Three use cases to" in the first goal.

Unsure whether "Constraints on how clients load the formats" can be parsed as a goal.

No mention of interaction with other IETF WG.

May I assume that WPACK also encompass the naming / retrieval of those web package ?

Nit " above properties. * Support", insert a CRLF ?

Nit: should "DRM" be expanded ?