Subject: [Wpack] WPACK BoF Notes

From: Patrick McManus <[email-masked]>
Date: Sun, 17 Nov 2019 23:28:59 +0800

Hi All,

I have few notes to share with the list in the role of chair for
Wednesday's BoF..

The proponents have updated their proposed charter a little bit. As this is
a potentially WG forming BoF we'll be talking about that proposal
extensively - it is located here as part of the meeting materials:
https://datatracker.ietf.org/meeting/106/materials/slides-106-wpack-proposed-charter-00-01
.and
I will reply to this message with a copy of it to seed any discussion
beforehand. Feel free to comment on the list ahead of time if you like -
there are fewer time constraints on the list of course.

Likewise, several of the presentations have been posted (3 of 5 I believe)
and I expect the others to be available on Monday. The meeting materials in
general, including these slides, are
https://datatracker.ietf.org/meeting/106/session/wpack

Before the meeting please make sure to read
https://tools.ietf.org/html/draft-iab-escape-report-00 which is the report
from the IAB Workshop on Exploring Synergy between Content Aggregation and
the Publisher Ecosystem (ESCAPE).

Our agenda, as of this time, is below. I look forward to our meeting on
Wednesday - see .you then!

-Patrick

# Overview

* IETF 106 - WPACK (Web Packaging) BoF
* 15:20 - 16:50	Wednesday Afternoon session II Room Collyer

* Minutes: https://etherpad.ietf.org/p/notes-ietf-106-wpack?useMonospaceFont=true
* BoF Proposal: https://trac.tools.ietf.org/bof/trac/wiki/WPACK
* BoF Proposed Charter:
https://github.com/WICG/webpackage/blob/master/IETF-WG-charter.md
* Mailing List Archive: https://mailarchive.ietf.org/arch/browse/wpack/
* Related Background: IAB ESCAPE Workshop report
https://datatracker.ietf.org/doc/draft-iab-escape-report/

# Agenda

* 5min Introduction -- Chair

## Background Presentations:
* 5min Community Networking Use Cases -- Spencer Sevilla and Matt Johnson
* 5min Pre-installed Websites Use Cases-- Brian Kardell (remotely)
* 5min AMP Use Cases -- Devin Mullins
* 5min Unsigned Bundle Sharing Use Cases -- Kinuko Yasuda (maybe remotely)

## Looking Forward

* 10min Use Case Discussion

* 10min Proposed Approach -- Jeffrey Yasskin

* 10min General Clarification and Discussion

* 20min Charter Review and Discussion

* 15min BoF Polls -- Chair

---

From: Patrick McManus <[email-masked]>
Date: Sun, 17 Nov 2019 23:31:26 +0800

This is the WPACK proposed charter text, also available at
https://github.com/WICG/webpackage/blob/0b0a67a71c983b9dc91f89edf8ebb2a5758568b3/IETF-WG-charter.md

-Patrick

Background

Webpages sometimes group multiple subresources into a single combined
resource to allow cross-resource compression and to reduce the overhead of
HTTP/1 requests. The W3C TAG (Technical Architecture Group) proposed a web
packaging format based on multipart/* , to give web browsers visibility
into the substructure of these combined resources. That has not seen
deployment and HTTP/2 did not make these bundles unnecessary as was once
expected.

These bundles are still needed. In countries with expensive and/or
unreliable mobile data, there is an established practice of sharing content
and native applications peer-to-peer. Untrusted web content can generally
be shared, but with the web's move to HTTPS, it is no longer possible to
share web apps over these channels
<https://github.com/WICG/webpackage/blob/0b0a67a71c983b9dc91f89edf8ebb2a5758568b3/IETF-WG-charter.md#wpack>
WPACK

The WPACK working group will develop a specification for a web packaging
format that efficiently bundles multiple HTTP resources. 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:

   - Efficient storage across a range of resource combinations. Three
   examples to be supported are: a client-generated snapshot of a complete web
   page, a web page's tree of JavaScript modules, and El Paquete Semanal from
   Cuba.
   - Safe web app installation after having been retrieved from a peer.
   - Low latency to load a subresource from a package, whether the package
   is signed or unsigned, and whether the package is streamed or loaded from
   random-access storage.
   - Being extensible, including to avoid cryptography that becomes
   obsolete.
   - Security and privacy properties of using bundles as close as practical
   to TLS 1.3 transport of the same resources. Where properties do change, the
   group will document exactly what changed and how content authors can
   compensate.
   - A low likelihood that the new format increases centralization or power
   imbalances on the web.

The packaging format will also aim to achieve the secondary goals described
in draft-yasskin-wpack-use-cases as long as they don't compromise or delay
the above properties.

The following potential goals are out of scope under this charter:

   - DRM
   - A way to distribute the private portions of a website. For example,
   WPACK might define a way to distribute Gmail's application but wouldn't
   define a way to distribute individual emails without a direct connection to
   Gmail's origin server.
   - Defining the details of how web browsers load the formats and interact
   with any protocols we define here.
   - A way to automatically discover the URL for an accessible package that
   includes specific content.

Note that consensus is required both for changes to the current protocol
mechanisms and retention of current mechanisms. 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) does not imply that there is
consensus around the feature or around how it is specified.
<https://github.com/WICG/webpackage/blob/0b0a67a71c983b9dc91f89edf8ebb2a5758568b3/IETF-WG-charter.md#relationship-to-other-wgs-and-sdos>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.
<https://github.com/WICG/webpackage/blob/0b0a67a71c983b9dc91f89edf8ebb2a5758568b3/IETF-WG-charter.md#milestones>
Milestones

   - Chartering + 3 Months: Working group adoption of use cases document
   - Chartering + 3 Months: Working group adoption of bundling document
   - Chartering + 3 Months: Working group adoption of security analysis
   document
   - Chartering + 3 Months: Working group adoption of privacy analysis
   document
   - Chartering + 3 Months: Working group adoption of signing document
   - Chartering + 18 Months: Use cases document to IESG
   - Chartering + 18 Months: Bundling document to IESG
   - Chartering + 24 Months: Security analysis document to IESG
   - Chartering + 24 Months: Privacy analysis document to IESG
   - Chartering + 24 Months: Signing document to IESG

On Sun, Nov 17, 2019 at 11:28 PM Patrick McManus <[email-masked]>
wrote:

> The proponents have updated their proposed charter a little bit. As this
> is a potentially WG forming BoF we'll be talking about that proposal
> https://datatracker.ietf.org/meeting/106/materials/slides-106-wpack-proposed-charter-00-01 .and
> https://tools.ietf.org/html/draft-iab-escape-report-00 which is the
> report from the IAB Workshop on Exploring Synergy between Content
> Aggregation and the Publisher Ecosystem (ESCAPE).
>
> * BoF Proposed Charter: https://github.com/WICG/webpackage/blob/master/IETF-WG-charter.md
> * Related Background: IAB ESCAPE Workshop report https://datatracker.ietf.org/doc/draft-iab-escape-report/
>
> # Agenda
>

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Thu, 21 Nov 2019 10:10:00 +0800

I see three distinct pieces of work here.

1) The container encoding
2) Determining the correspondence to HTTP
3) Working out what signatures actually mean

Developing an encoding format is relatively straightforward, we don't even
need to pick a single one. If people are happy having separate encodings to
support signed content and signed/encrypted content, that is fine with me.

But if this group is chartered with encryption excluded from the encoding
considerations, then that is a commitment to two encodings in perpetuity.
With the best will in the world, merging the streams two years after they
have diverged is a non-starter.

So what I would like to see is encryption in scope for the WG but not
decryption. And that is not a joke. Encryption is easy. The hard part is
deciding how to decrypt. And that is a problem that is properly outside the
scope of the WG.

The Mathematical Mesh provides two separate decryption schemes. One is the
use of EARLs, the other is a key distribution center scheme that gives a
subset of DRM capabilities I call confidential document control (preventing
redistribution of the plaintext is out of scope).

And WPACK need not depend on the Mesh for decryption capabilities. Nor
should it. All the package needs to do is to provide a means of identifying
the key used for encryption (hash of the public key or the symmetric key),
the key exchange information and provide an open extensible structure for
throwing in whatever advice you might want.

So I would like to see the 'DRM' etc. parts removed from the charter scope
and instead have encryption in scope and decryption out of scope.

Now the question we might want to consider is whether the same should be
true for the interpretation of signatures... I am not sure. It is certainly
a large and complex piece of work and the HTTP part is also large and
complex.