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