[Wpack] Problem statement and scope for BoF

[Jeffrey Yasskin <[e-mail]>]

I've drafted an initial problem statement and scope for the WPACK
working group we're hoping to create at a BoF at IETF106 in Singapore.
I've pasted it below, and you can suggest changes at
https://bit.ly/wpack-draft-charter. I intend to draft a charter once I
have some indication that the group here likes the scope I'm
proposing.

Thanks,
Jeffrey

Problem
=======

There are large populations of users who have trouble making direct
connections to HTTPS origin servers over the public internet. For
example:

* 55% of internet users live in countries where political, social, or
religious content was blocked online.
(https://freedomhouse.org/sites/default/files/FOTN_2018_Final%20Booklet_11_1_2018.pdf).

* Other users run out of paid-for data in their mobile plan part-way
through a month, or aggressively disable mobile data to make sure it's
not wasted.

* Others use satellite connections with high latency and packet loss.
Anecdotally, see
https://meyerweb.com/eric/thoughts/2018/08/07/securing-sites-made-them-less-accessible/.

These users currently have to, at best, tell their browsers to
pre-fetch sites when they have a cheap real-time connection available
or wait until they find such a connection, and at worst, can't browse
the content at all.

Even users with highly-available internet connections want to be able
to read and interact with web pages as quickly as possible after
clicking a link. Needing to make extra connections in the critical
path, and having multiple connections competing for bandwidth without
the ability to prioritize, interfere with that goal.

All of these users deserve to know whether the content they're reading
or application they're running actually comes from the origin it
claims, and the publishers of those origins value their users being
able to verify that the content is authentic. Both groups also value
the users' ability to store data within websites and web applications
(e.g. preferences and content they've created) and have it available
the next time they load the same URL.

Scope
=====

1. Define a way to package the public portion of one or more websites
or web apps into one or more files that can be distributed and used
without a direct connection to the origin server.

2. Define a way to sign these packages such that the result gives the
recipient confidence in the integrity and authenticity of what they
received. This work will ensure that a client loading a Web Package
signed using the initial specification has security and privacy
properties that are at least as good as a transferring the contained
resources over HTTPS+TLS1.3 from the publishers' origin server(s)
except that:

    a. Packages do not guarantee confidentiality, but if the channel
that transfers the package provides confidentiality guarantees,
packages at most compromise that by revealing information to the
original origin server of the resources in the package and by making a
TLS1.3-or-later private connection to that origin server.

    b. Packages only guarantee their contents were vouched by the
origin servers' keys within the life of the signature, not during the
life of the connection(s) that transferred them.

    c. Packages do not provide any of the security "guarantees" of the
DNS system.

    d. A package generated for one client can be shared to other clients.

    e. TBD: Are the above sufficient? Can/should we give the WG
permission to change this list?

3. Optionally define a way for clients to check that an origin server
still vouches for its package in real time.

4. Define a way for an end-user to package their view of a site in
order to show a peer what they saw. This could just be an update of
RFC2557 (MHTML) but could instead be an un-signed variant of the same
format as above. This kind of package will not guarantee integrity or
authenticity from the origin server, but might from the end-user who
packaged the site.

5. Define the resulting security and privacy model and compare it to
the status quo security and privacy model of HTTPS. Search for places
the existing web platform depends on the fact that HTTPS provides
transport security and describe how those have to change or not given
Packaging's addition of object security. This may involve working with
W3C groups like WebAppSec and PING.

6. Formats that this group defines should be usable efficiently:

    a. When individual contained resources are either small (~10s of
bytes) or large (~GB),

    b. When the total number of contained resources is either small
(1) or large (thousands for the initial format with enough
extensibility for an update to expand it to millions or billions),

    c. When the total size of all contained resources is either small
(~KB) or large (~TB (matching El Paquete Semanal in Cuba) initially,
with enough extensibility for an update to expand it to EB), and

    d. When the format is either streamed to the client or loaded from
a slow but random-access medium like an SD card.

7. Ensure that any formats or protocols this group defines can be
migrated to better cryptography when their original cryptography is
broken.

8. As long as it doesn't compromise or delay the above goals, try to:

    a. Support signed statements about the content beyond just
assertions that it's the representation of a particular URL. For
example, that it appears on a transparency log, that it passed a
certain kind of static analysis, or that a particular real-world
entity vouches for it.

    b. Address the threat model of a website whose frontend might be
compromised after a user first uses the site.

    c. Support books being published in the format.

    d. Support long-lived archival storage.

    e. Optimize transport of large numbers of small same-origin resources.

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

    g. Allow publishers to efficiently combine sub-packages from other
publishers.

Out of scope
------------

1. DRM

2. 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.

3. Defining the details of how web browsers load the formats and
interact with any protocols we define here. The W3C and/or WHATWG are
more appropriate fora for that effort.

4. A way to automatically discover the URL for an accessible package
that includes content for a blocked or expensive-to-access URL that
the user wants to browse.