[Wpack] [wpack] Minutes from the IETF105 side meeting

[Yoav Weiss <[e-mail]>]

Hello all,

Minutes from today's side meeting are now available
<https://docs.google.com/a/google.com/document/d/e/2PACX-1vR-CltWycM5kelXF0M-eESSSN_cbOFI-v7no9SsMauL0YGqdgNOOB_Wsra0eJVEUdQy06wMlnqAXRP-/pub>
.

Copying them here for safe keeping:
Web Packaging side meeting - IETF 105


Participants:

Brad Lassey (Google), Greg Grothaus (Google), Devin Mullins (Google), Brian
Trammell (Google), Ted Hardie (Google), Chris Wood (Apple),

Tommy Pauly (Apple), Wendy Seltzer (W3C), Mark Nottingham (aka mnot;
Fastly), Martin Thomson (Mozilla), Jeff Hodges (Google), Kinuko Yasuda
(Google), Ryan Sleevi (Google), Eric Rescorla (aka EKR; Mozilla), Alissa
Cooper (Cisco), Dan York (ISOC), Zahed Sarker (Ericsson), Rich Salz
(Akamai),  Mike Bishop, Lucas Pardue, Sam something, Spencer (University of
Washington), Dan Gillmor (aka DKG; ACLU), Gail? something (ACLU), Ben Kaduk
(Akamai),

many more…..

Jyasskin:

Summary of workshop

   - Publishers were present. Seem like they like the concept of web
   packaging
   - Ted Hardie - Rightsmesh - a group in Canada working on peer to peer
   delivery of applications, not currently signed. Concerned about many of the
   same things, but come from a different Ecosystem. So maybe we can expand
   the context, to look at these other use-cases.
   - EKR - collective action problem - people whose content is being
   packaged now have an incentive to package it themselves
   - EKR - they need a mechanism to pickle TLS transactions
   - Jeffrey Yasskin - presented evidence that users want to share apps
   - Rich Salz- “not much worry” is overly positive. People were concerned.
   - Dan York - my takeaway: some people are looking for a discoverability
   thing, a common format to get your content to distributors. Others want
   availability (p2p, caching).

Charter Discussion

   - Jeffrey Yasskin - identified a few essential use-cases and some
   opportunistic ones


   - Essential


   - Signed - P2P sharing and privacy preserving prefetch
   - Unsigned - user created untrusted web page


   - Opportunistic


   - Signed as HTTPS -  to avoid censorship
   - Signed - books, security review, cross-CDN serving, Signature based SRI
   - Unsigned - faster subresource loading, archive,


   - Dan York - “discoverability” - getting into distribution platform to
   replace proprietary formats
   - Daniel Kahn Gilmore - Same as “privacy preserving prefetch”
   - Jeffrey - depends on which hop is involved. PPP is from client to
   cache and discoverability if from cache to server
   - Dan - Not really
   - Jeffrey - another use case “encrypted caches” - cache can hold
   non-public info
   - Ben Schwartz - creating widely-shared secrets is not great. If you
   don’t have many users, that’s not interesting. If you do, the key is widely
   shared. Interested in TLS forwarding design that would also resolve the
   privacy preserving prefetch


   - I do think the use case is interesting, but not by encrypting the
   cache content


   - DKG - a different argument, separable from the rest so people can work
   on that as a different project
   - EKR - useful to clarify the purpose of the use case. Purpose is not to
   conceal the request from the origin, but to restore caching that TLS broke.
   Millions of people download e.g. windows updates. Need to restore that.
   - Alissa Cooper (Cisco) - useful for content that’s not widely shared,
   as it can save bandwidth in some scenarios
   - Zaheed Sarker (Ericsson) - blind caching has many benefits, so would
   be good to revisit these use cases. We should look into this.
   - Brian Tramell - Another way to look at Web Packaging is turning the
   model from transport security to object security. Naively you can say your
   mime type is …..
   - Ted - Dan wanted to create a single format. Can we decouple the
   signing from that format?
   - Mike Bishop - had a slide about adding a RTT to get something to
   origin. [encryption] is the only way to enforce that clients do it.
   - Jeffrey - can also force an RTT to regain trust
   - Mike - currently you publish something with an RTT, but CDNs can purge
   it if it has an error. Need the same here.
   - Ben Kaduk (Akamai) - changing from transport to object is a good way.
   But claiming the object is confidential will require thinking, as there are
   many side channels
   - Brian - not easy to do but easy to separate. From a project planning
   standpoint - tying together would give you one way to do caching and
   distribution. A lot of hairy details in the origin signing. And lots of
   them in encrypted caching.
   - Jeffrey - good input to charter discussion
   - Dan - so to understand, you think restoring caches is a separate thing?
   - Brian - this should not be a dependency on web packaging, but the
   other way around might be good
   - Dan - need to see how we do caching in a world of HTTPS? So the
   availability side of this is important. But I do see what you mean
   - C. Su (Hughes) - Discovery of caches is the hard problem
   - Ted - Even if all the content is public, the role here is distributor,
   not aggregator
   - Mnot - stand by the paper I submitted. Caching is not just the
   mechanism, also incentives. Useful for limited cases like OS package
   distribution. If you want to design this so that publishers have a very
   strong reason to do this, you need to design this while considering the
   incentives. Publishers need to opt-in to a system where a random cache can
   serve their content. Forward caching failed because people didn’t know
   whether to trust the quality of the cache. It’s a large hairy ball of a
   problem.
   - Kenji - Nothing that prevents JS or data fetches from the server
   - DKG - I think mnot said that publishers won’t participate unless they
   get metrics from users, and encryption mechanism are not about preventing a
   ping back
   - Mnot - they’d want to make sure content is served fast, available,
   integrity-protected, generally good UX.  want to know how much was served,
   but not a lot of metrics. so more about quality of experience, unless we
   have something better than forward proxies. Publishers don’t want to think
   about that. Roberto Peon has a proposal (proxy.pac?) that can offer a
   better UX here. But it’s not “if we build it they will come”
   - Wendy Selzer - appreciate focusing on fewer use-cases as the core.
   it’s helpful to focus, rather than grow something that’s big and complex
   and serves none of the use cases very well. helps think about the threat
   model, etc. more clearly.
   - Spencer (UW) - incentives align. People going to TLS, but TLS is also
   used for content that’s not really secret. There’s a world of websites that
   use TLS just to ensure integrity
   - Jeffrey - none of the proposal is for discovery
   - Mnot - a lot of secondary use-cases, but I don’t think we should say
   much about them. not a fan of “hope-based standardization”. Should focus on
   the core use-case. Opportunistic use-cases should be buried in an appendix
   with a large warning
   - EKR - the use case of P2P sharing is required. Want to push back on
   the notion that websites use TLS for integrity. There’s a reason we enforce
   integrity cypher suites and why we think confidentiality is important
   (they’re hard to reason about, and users want confidentiality even if pubs
   don’t).  click-tracking is bad. engineering things that reenforce that
   idiom is bad.
   - DKG - wanted to point out that the interest of the site operator is
   different from the user’s. Web sites operators don’t care about
   confidentiality, but users do. User expectations are not met today “because
   the web is a rolling privacy nightmare”. But it would be nice to meet some
   of them. Brian’s point about moving from transport to object is great.
   Binding the object model into the HTTPS origin scares me. I don’t
   understand all of the web. Much of the web’s security is devoted to
   understanding what the origin is. We built a lot centered on that model,
   and then changing the concept of origin shakes up all the things that are
   built on top of it. Would love to enumerate all the things that depend on
   the origin, and see if those work under object security.
   - Jeffrey - good segue
   - Brian - share the same kind of unease. Throwing all eggs into a single
   basket. Signing bits of data with the origin and them moving it somewhere
   else doesn’t seem too complex to reason about. It’s work that needs to be
   done, but should be in scope for the working group (he WG, unless it turns
   out to be super researchy). it needn’t be a precondition to starting the WG.
   - Mnot - is that a gating factor?
   - Brian - Not a gating factor, but some analysis is required, like TLS
   1.3
   - Brian - reasoning about encrypted caching is a lot harder. in signed
   exchanges, data & metadata move with each other. tracing the metadata
   through an encrypted caching system requires tracing where the key’s been
   and how it moves. potentially very many actors involved in key distribution.
   - MT - To go back to user expectations of privacy. There’s a massive
   degradation right now, that we need to stop. Click tracking is an emergent
   property of the web that some of us are unhappy about, and very difficult
   to remove. But taking a tilt at this use case wants to enshrine that in the
   architecture. Taking a property that has negative consequences and nail it
   down and commit to it. This makes me nervous. Up until this point I’ve been
   ambivalent about this, and this tips the point. It creates a new surface
   area for security issues. Up until now I was fairly confident that we’re
   not making things much worse, but this change that.
   - Ted: Interesting to think of side-meetings as dystopian selection
   mechanisms. I don’t think we have that much power to choose our dystopia,
   or else I wouldn’t get out of bed in the morning. “let’s make sure we keep
   current dystopia”. We can however understand our current model. Click
   tracking is a good example. We were talking about a mechanism to change
   security properties from transport to origin. But the mechanisms were also
   a combination of transport and application (headers). So we have to take
   the pieces from both transport and headers to move it here. That’s why
   we’re talking about signed exchanges and not a mime type that does the
   same. “Secured by a combination of an object and its origin, where origin
   doesn’t require transport”-ish…
   - EKR - Agree with Ted. Currently security model is a 5-10 year attempt
   to construct something out of an even worse dystopia. Almost understandable
   now, but it’s a very brittle system.
   - Jeffrey - when do we try a BoF. Too early would be a waste of time.
   Some questions that the bof presentation needs to answer. Want to find
   questions people think need answering
   - Mnot - start to form an opinion that this will be two BoFs, we need
   indication from Area Director. A BoF in Singapore would draw out questions
   that ADs need to answer and then we do a. . second one
   - Rich - saying “no” is not a waste of time; it’s scientific method.
   Also, Asia gets less attendance, so better participation if it’d be North
   America based...
   - Ben Schwartz - my impression is that there are different people with
   different use cases, each of them is complex with multiple components, one
   of which could be web packaging. Feel like nobody sketched those out in
   great detail - to compare packaging vs. no web packaging. Missing here to
   explain the net value of web packaging. e.g. community-based local caching;
   what it would take to be widely-used and viable. Would like to see that at
   the BoF
   - Alexey: tried hard to avoid the mic. You’re already effectively having
   a BoF, with a very constructive discussion. Let’s go for a BoF, and maybe
   we’d need to do this twice e.g. to narrow scope. Also, if not in Singapore,
   it won’t be my problem. (so don’t delay till Vancouver)
   - Alissa Cooper: Agree this is far more mature than most things we
   receive more most BoFs and WGs. There’s a lot of people who would be
   interested in that and are not in this room. Time to open to a wider
   audience. Publisher input: good to get that feedback on the list in the
   next 4-5 months. My sense of the workshop: more detailed questions about
   web security model; publishers don’t have a nuanced view on them.
   - You can get input from publishers on the list for higher level
   questions, and that’s fine
   - Mnot: agree. Publishers won’t show up but can comment on the list;
   would be nice to solicit more input. What Ben said, looking at other
   solutions and compare them, that would be a huge effort, so it’s not
   realistic to block on that. But e.g. blind caching is something people
   looked at it, so we can compare here. The solution there had many of the
   same tradeoffs. We decided not to do it, and it was a more mature proposal.
   So we can look at existing unsuccessful proposals. But it could be just
   implementer interest, but would be good to understand.
   - Dan - should move ahead. Main question is scoping and what we should
   focus on. Because there were so many use-cases we discussed.
   - Ben Kaduk - Heard interesting and important questions, but questions
   that don’t need to be answered before a BoF. But we need to recognize that
   these open questions can end up in a “no”
   - Sam - proposed non-goals?
   - Jeffrey - encrypted caches, math mesh
   - Jeffrey - heard strong advice to go for Singapore, so will start
   working on a draft charter