Minutes IETF106: wpack
minutes-106-wpack-00

IETF 106 WPPACK BoF Minutes

Mcmanus: our purpose is to recommend (or not) the formation of a working group,
and recommend a charter

Agenda: present lots of use cases, describe approach, discuss.

Presentation: Community Networking Use Cases
Matt Johnson:

small, grassroots networks -- few business relationships, local infrastructure,
2-3 Mbps backhaul for 100s of users, but local bandwidth is much higher.

interactions are local but use the big social networking platforms.

Use WPACK to cache things rather than force repetitive downloads.

Presentation: Pre-installed Websites Use Cases
Brian Kardell:

Embedded systems use web tech now. many use file://. some use localhost.

Devices, when first turned on, might not have a connection. -- bootstrap the
content using wpack.

Need trust model for a particular package for a device.

Presentation: AMP Use Cases

Devin Mullins:

AMP has a general goal for predictably fast loading and sets a number of
requirements that help towards this, toghether with some security guarantees
and sane failure handling.

Caching behaviour needs to be expressive, content providers play a large role
in things and so the exposed Interface needs to accomodate both their
requirements and the technical requirements.

Bundles are generalyl cached in a non-content-operator/owner domain, so must
satisfy that domain requirements

Signatures (SXG) are also important

Presentation: Unsigned Bundle Sharing Use Cases

Kinuko Yasuda:

No signatures

Allow people to save a website as a bundle and share it. (e.g. use content on
an airplane)

Content owner can control the generation of their own bundles via their own
code executed on the client-side (and maybe server-side too? - some links to
open source projects in Go and node.js)

Use Case Discussion

mnot: I'm surprised this is all in scope. Are all presentatiosn use cases?
jyasskin: yes
mnot: don't see a natural path for why this technology is the right solution.
For poorly connected netwroks, we've seen some proposals before in HTTP WG but
they didn't work out for various reasons e.g. technology or security Maybe
leave some things out of the charter. Ted Hardie: DKG raised the privacy issue
too. It kind of looks like a CDN. P2P is different. community networks would
have a central node that can mitigate some of the problems

phb: can't understand a packaging format without encryption. Don't think today
should be think of a bunch of web technology that assumes even the data sits on
servers unencrypted. Encryption hsould be required.

rpeon: if intent is to support/speed up offline resources, is this restricted
to HTTP only.

mallory ?: is AMP a requirement or a non-requirement

devin: the intent is to widen out thinkgs

mallory: starting with the use case and experience of the community netwrok is
better than focus on the intermediary. There are several actors and much of the
focus/propoent has come from intermediary

jyasskin: thanks, community networks were a inspiration

DKG: confidentiality and privacy, they are not the same thing. How much of the
content should intermediary be able to see? Howe much of the user activity
shoudl the intermediary be able to see? TLS is a web security model. This is an
object security model.

Ted hardie: can you clarify what is meant by the intermediary can see what the
user does?

dkg: with the transport model, the intermediary can't see anything after the
referral. In this model, as a content proxy, you see all the transactions. Ted
Hardie: so intermediary == distributor of the bundle(s)? dkg: yes. A big bundle
is cumbersome overhead, but smaller bundles make the ares of interest very
clear. Ted: lets take it offline but I generally agree. E.G a weekly Cuban
digests is quite big but the p2p distribution is quite cheap - from a bandwidth
perspective and leak about data dissemation perspective dkg: yes, larger
bundles are more private. ted: content creators need to think about what is in
the their bundle. AMP is a simple version of the problem. mcmanus: can we wrap
thispart of the conversation up? dkg: personally distributing the bundle is the
origin; this will have implications for the client and intermediary and the
incentives are wrong.

Proposed Approach
Presentation:
Jyasskin:

all this is preliminary

subset of cmbo that contains a set of sections, constrains certain aspect of
content generation content negotiation using mnot variants proposal manifest of
the package is a URL in the package, W3C will specify more details some
sections may be "critical" and the client MUST understand list of authorities
(certs) to authenticate package need to include full root of authority such
that authenticatation can work offline e.g. X.509 certs all the way up to root
suggests the working group think about counter-signatures because there is no
design for it right now web archive pakcages a bunch of stuff and wants to
avoid that content conflicting in some bad way origin turst: sign a cert just
like a TLS cert. some dangers are intrinsic, others avoided by desing defined
opt in like cert extensions or CAA records, damage limitiation via 7-day
validity don't allow stateful headers to avoid packaging personalized data 1
signature for all is attackable, better to have multiple signatures john
willander provided some analysis aboutthe ability to identfy users, so a
mitigation is offered does shift to object security model create more
vulnerabilities?

General Clarification and Discussion
mcmanus: questions comment about the presentation or technology?
peon: when one resource changes, how would we accomplish that
jyasskin: we could do a patch format, but we haven't. shouldn't hold back until
we fully define patch peon: would patches be in scope for the WG? MT: how many
have read the escape workshop report? [Lots] outside bundles are interesting.
tying it to HTTP so tightly is debatable. no request header fields is a curious
choice. jyasskin: it would be possible to add them. MT: most of my reservations
(and many others) is the notion of taking content from any distribution
channel, and we identified some problems there, and substituting content. I
haven't seen, to DKG's points earlier, a satisfactory answer. That makes me
uncomfortable. The space/specturm of use cases is quite diverse andthe solution
might not be entirely suitable trammell: response to MT. the encoding parts are
uninteresting, seems OK. object security model is interesting. playing
vulnerability golf. We tried to figure it out in Montreal and got pretty far.
IT shouldn't be me, ted and DKG that hash this out over a drink. mcmanus: the
purpose of a working group is to discuss these things phil hambeig: i do have
firm views of encoding. not just picking use cases you want to solve; also find
the one that encapsulates the whole problem. moving to object model, package
stands for the webserver. mapping it to http: if you provided a format, this
might be the use case that led to a correct design. jyasskin: you made an
interesting observation that the package acts as a server but I think it is
better to think of it acting as a cache, which is why things like variants work
well. community networking is the use case i had in mind. mnot: i started
escape because we are concerned about the power dynamics. those are concerning,
but we should not worry about it here. it is not a direct effect of this
proposal. not against this proposal. risk when we put private data in the
package -- publisher, don't do that. similar to shared compression in http,
which has slippery security properties. here, same engineers are saying this is
OK. developers tend to overuse packages -- may take us back to a web of pdfs.
needs to work with http caching model jabber (chris lemon): seems designed for
google amp. others get 80% -- should wg focus on those 20% ted hardie: 2
responses. as a proponent leaving stuff out would make me sad, the other reason
is an IETF reason - building blocks. Having many use cases lets us build better
building blocks so we shoudl include more than 1 use case: AMP and community
networks satisfies that. charter should include more than one use case. martin
duke: is the histrocial archiving use case included in this? everyone: yes
mnot: it is important to realise that these are building blocks, but that many
parts of the ecosystem will rely on these blocks. Things won't happen unless
other places pick up the clocks and fill in the gaps - that affects the
possible success of this proposal

Charter Review and Discussion
sean turner (opens google doc): now it's time for some group editing. [starts
reading the charter draft aloud]

MT: it is not true that we cannot secure web apps over constrained edge
channels. mnot: last sentence of first paragraph will be read as "a bundle is
required for performance", which is not true and recommend deleting it bishop:
"the previous attempt to solve the problem was not deployed" please explain why
jyasskin: answering martin, browsers require secure context and you don'tget
that with files [to mark] there is a webpack program that is super-heavily
used; you have to bundle to get good performance rpeon: bounced the WPACK idea
of two folks that said this is not completely crazy. mention of H2 server push
and it is pertinent to consider that mnot: solved by changing HTTP/2 to HTTP/2
server push? trammell: we're wordsmithing the background section ben schwarz:
can we not refer to a specific thing in Cuba (el paquete semanal) trammell: can
I comment on something you haven't read yet sean: no mnot: was web pack
sufficiently defined, is a  liason required trammell: [to aspects related to
cryptography/security]I undesrtand where this came from and it gives me anxiety
ted: this is not granular enough. must talk about handling of items in bundle
as well. trammell: use the headings in the Jeffrey's slides peon: be more
specific about security and privacy properties. bishop: don't drop a third
example, just don't refer directly to a Cuban instance mcmanus: we should move
to things out of scope dkg: the properties that TLS 1.3 provides goes away if
someone else delivers the data mcmanus: are you suggesting a bar that the wg
would have to meet? dkg: how does one compensate for the change in
confidnetiality and privacy aspects of the transfer mallory: we keep saying
content authors; we actually mean publishers. that would be more accurate. we
should also think more about goals for publishers. 'power imbalances' not the
only issue for publishers; also monetization. MT: one thing missing is one
clear articilation of he constraints people running this should operate in
order to maintain guaratnees. agree with dkg. we are setting a new bar that
require meeting a brand new set of requirements. that relates to things that
mnot, jeffrey havem mentioned. along with personalisation. we should capture
these and do an anaylsis to ensure that we can get this right. Another point:
safe web app installtion is not a goal I am interested in puruing. There's a
lot wrapped up in this. Could we solve AMP and constrained backhaul only? Peon:
i don't want to be sued for being here because no one put a license on it. we
should consider that here. ben schwarz: i agree with MT. 'out of scope for how
browsers load format' -- no, we should list constraints. this could actually be
a victory for privacy over HTTPs e.g. if servers push bundles this may have
better privacy properties. felix handt: one of the things that satands out to
me is something not included in the scope. discovery mechanism has been punted,
many descriptions include only manual user discovery sean turner: charter
review - items out of scope - no part of current draft has no presumption of
making it through the WG process. peon: i don't understand why private stuff is
out of scope? could increase security in some cases jyasskin: you need to
protect private information peon: why not say that? mcmanus: not enough to time
to discuss this

BoF Polls

sean turner: do you understand the issue being proposed for the wg? (strong hum
in favor) well defined enough for a wg? (moderately strong hum in favor) --
assuming charter revisions are done problem that should be addressed by the
IETF? (unanimous hum in favor) enough people to work on the problem?
(significant hum in favor)  -show of hands about 20 will help from several orgs
are the proposed deliverables corrent and well articulated? (50-50 hum) next
steps: revise the charter do some work. not burn thing down mnot: this revision
will happen in public? sean: yes