Return-Path: X-Original-To: wpack@ietfa.amsl.com Delivered-To: wpack@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 40AE3120956 for ; Tue, 23 Jul 2019 15:36:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yoav-ws.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L6vzfSQKvXnz for ; Tue, 23 Jul 2019 15:36:02 -0700 (PDT) Received: from mail-wr1-x434.google.com (mail-wr1-x434.google.com [IPv6:2a00:1450:4864:20::434]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A9BA4120352 for ; Tue, 23 Jul 2019 15:36:01 -0700 (PDT) Received: by mail-wr1-x434.google.com with SMTP id p17so44753019wrf.11 for ; Tue, 23 Jul 2019 15:36:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yoav-ws.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to; bh=OvuZPfxFXdgQ/oCkeFE/PT9ySRk0icP67OYQBB5QpYo=; b=x4vZ6low0thgLbsAWvLdmodG8v4buScwG7ImIkYrz8aXB6LMoQaFU2rOZNL05NrhKf EUzDnNltbh8rGub6DEA3iHhZvTYEn4N/dIvd5KQouekjxbbADhs27aJamug8hcIpURZP W1S90W6ZprAl/9OyfRlsGVjMEDnjFl2RVaWABksWR9tfCdB5U/crvEwdS4GeQK4hyIiy 67kfbAFi865GTHqq6BiYNRmv+asdSBRhTdCvLQ5P/QWtUSkn5X27hEVNP71ASenxxghD WsIOreOEFlHUocB9CtfiyU3+KfF/cLf1ZRJki6IQATEhNQ3UKATwwsvxaYX3jXmlhgp5 csww== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=OvuZPfxFXdgQ/oCkeFE/PT9ySRk0icP67OYQBB5QpYo=; b=H8G5e6Dukbg3rMPPhfn+K+kd2aQiuHt1IAPK34hbcEMjw1OPshQZ3WI4BaQtCV0k4j sTVUndY/erwzqMsH4kkD9SWRNXly4dMRTrJPPnnNHLnp/2XusdiNMoHTi6DbH662UMAk iufwFBFDm9Ntq5xhkYsr+LGzTBSScb8R+c/g9o/Wt6IwXz4oeoyyO/FjHgdjBV6LzUNt 6S2jmWOiOv8R1Mu0NK9ori0Bw2UPxytnsjqU3yfQVUV27nFLmUVKrA2xRRXdDRDHNdcP T+Kj/Sp8oeKqKE/O/Vanl+Y9lhOZfAcF4wIYLWKYszohk547m2cO/BHw92FWOMji8I/N ILMQ== X-Gm-Message-State: APjAAAVy8Hvp4r1kelHb3CtgZfyo8kZ36VgGoGYsPyW4G82/ES66hxiu SpCRC9DJFvcdJ43TC8x2F5u+YEiP2e+WmLtb8Zau4xkyL0w= X-Google-Smtp-Source: APXvYqyZIWEgxG2ajfHV70g1b9dKqJpZ79woYVloxsJwWBqqz28r1Bu6hZ3V0Mqj1lZF303fQ2evFvq2KpxKPnNFSCs= X-Received: by 2002:adf:f94a:: with SMTP id q10mr59815226wrr.341.1563921359618; Tue, 23 Jul 2019 15:35:59 -0700 (PDT) MIME-Version: 1.0 From: Yoav Weiss Date: Tue, 23 Jul 2019 18:35:43 -0400 Message-ID: To: wpack@ietf.org Content-Type: multipart/alternative; boundary="00000000000018e448058e60d115" Archived-At: Subject: [Wpack] [wpack] Minutes from the IETF105 side meeting X-BeenThere: wpack@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Web Packaging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Jul 2019 22:36:07 -0000 --00000000000018e448058e60d115 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hello all, Minutes from today's side meeting are now available . 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=E2=80=A6.. 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- =E2=80=9Cnot much worry=E2=80=9D 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 SR= I - Unsigned - faster subresource loading, archive, - Dan York - =E2=80=9Cdiscoverability=E2=80=9D - getting into distributi= on platform to replace proprietary formats - Daniel Kahn Gilmore - Same as =E2=80=9Cprivacy preserving prefetch=E2= =80=9D - 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 =E2=80=9Cencrypted caches=E2=80=9D - cache = can hold non-public info - Ben Schwartz - creating widely-shared secrets is not great. If you don=E2=80=99t have many users, that=E2=80=99s 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 bro= ke. Millions of people download e.g. windows updates. Need to restore that. - Alissa Cooper (Cisco) - useful for content that=E2=80=99s not widely s= hared, 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 yo= ur mime type is =E2=80=A6.. - 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 c= an serve their content. Forward caching failed because people didn=E2=80=99= t know whether to trust the quality of the cache. It=E2=80=99s a large hairy ba= ll of a problem. - Kenji - Nothing that prevents JS or data fetches from the server - DKG - I think mnot said that publishers won=E2=80=99t participate unle= ss they get metrics from users, and encryption mechanism are not about preventin= g a ping back - Mnot - they=E2=80=99d want to make sure content is served fast, availa= ble, integrity-protected, generally good UX. want to know how much was serve= d, but not a lot of metrics. so more about quality of experience, unless we have something better than forward proxies. Publishers don=E2=80=99t wan= t to think about that. Roberto Peon has a proposal (proxy.pac?) that can offer a better UX here. But it=E2=80=99s not =E2=80=9Cif we build it they will c= ome=E2=80=9D - Wendy Selzer - appreciate focusing on fewer use-cases as the core. it=E2=80=99s helpful to focus, rather than grow something that=E2=80=99s= 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=E2=80=99s not really secret. There=E2=80=99s a wor= ld 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=E2=80=99t think we shou= ld say much about them. not a fan of =E2=80=9Chope-based standardization=E2=80= =9D. Should focus on the core use-case. Opportunistic use-cases should be buried in an append= ix 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=E2=80=99s a reason= we enforce integrity cypher suites and why we think confidentiality is important (they=E2=80=99re hard to reason about, and users want confidentiality ev= en if pubs don=E2=80=99t). click-tracking is bad. engineering things that reenforc= e that idiom is bad. - DKG - wanted to point out that the interest of the site operator is different from the user=E2=80=99s. Web sites operators don=E2=80=99t car= e about confidentiality, but users do. User expectations are not met today =E2= =80=9Cbecause the web is a rolling privacy nightmare=E2=80=9D. But it would be nice to= meet some of them. Brian=E2=80=99s point about moving from transport to object is = great. Binding the object model into the HTTPS origin scares me. I don=E2=80=99= t understand all of the web. Much of the web=E2=80=99s 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 ar= e built on top of it. Would love to enumerate all the things that depend o= n 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 somewher= e else doesn=E2=80=99t seem too complex to reason about. It=E2=80=99s work= that needs to be done, but should be in scope for the working group (he WG, unless it tur= ns out to be super researchy). it needn=E2=80=99t be a precondition to star= ting 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=E2=80= =99s been and how it moves. potentially very many actors involved in key distribut= ion. - MT - To go back to user expectations of privacy. There=E2=80=99s a mas= sive degradation right now, that we need to stop. Click tracking is an emerge= nt property of the web that some of us are unhappy about, and very difficul= t 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=E2= =80=99ve 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=E2= =80=99re not making things much worse, but this change that. - Ted: Interesting to think of side-meetings as dystopian selection mechanisms. I don=E2=80=99t think we have that much power to choose our = dystopia, or else I wouldn=E2=80=99t get out of bed in the morning. =E2=80=9Clet= =E2=80=99s make sure we keep current dystopia=E2=80=9D. 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 al= so a combination of transport and application (headers). So we have to take the pieces from both transport and headers to move it here. That=E2=80= =99s why we=E2=80=99re talking about signed exchanges and not a mime type that do= es the same. =E2=80=9CSecured by a combination of an object and its origin, whe= re origin doesn=E2=80=99t require transport=E2=80=9D-ish=E2=80=A6 - EKR - Agree with Ted. Currently security model is a 5-10 year attempt to construct something out of an even worse dystopia. Almost understanda= ble now, but it=E2=80=99s 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 questio= ns that ADs need to answer and then we do a. . second one - Rich - saying =E2=80=9Cno=E2=80=9D is not a waste of time; it=E2=80=99= s scientific method. Also, Asia gets less attendance, so better participation if it=E2=80=99d= 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, o= ne of which could be web packaging. Feel like nobody sketched those out in great detail - to compare packaging vs. no web packaging. Missing here t= o explain the net value of web packaging. e.g. community-based local cachi= ng; 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=E2=80=99re already effectivel= y having a BoF, with a very constructive discussion. Let=E2=80=99s go for a BoF, = and maybe we=E2=80=99d need to do this twice e.g. to narrow scope. Also, if not in= Singapore, it won=E2=80=99t be my problem. (so don=E2=80=99t delay till Vancouver) - Alissa Cooper: Agree this is far more mature than most things we receive more most BoFs and WGs. There=E2=80=99s a lot of people who woul= d 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=E2=80=99t have a nuanced view on them= . - You can get input from publishers on the list for higher level questions, and that=E2=80=99s fine - Mnot: agree. Publishers won=E2=80=99t show up but can comment on the l= ist; 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=E2=80=99s= 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 propos= al. 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=E2=80=99t need to be answered before a BoF. But we need to reco= gnize that these open questions can end up in a =E2=80=9Cno=E2=80=9D - 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 --00000000000018e448058e60d115 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hello all,

Minutes from today's sid= e meeting are now available.

Copying them h= ere for safe keeping:
Web Pack= aging side meeting - IETF 105


Participants:

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

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

<= span class=3D"gmail-c3" style=3D"vertical-align:baseline;font-size:11pt">ma= ny more=E2=80=A6..

Jyasskin:

Summary of workshop

  • Publishers were present. Seem like they like the concept = of web packaging
  • Ted Hardie - Rightsmesh - a gr= oup in Canada working on peer to peer delivery of applications, not current= ly signed. Concerned about many of the same things, but come from a differe= nt Ecosystem. So maybe we can expand the context, to look at these other us= e-cases.
  • EKR - collective action problem - peop= le whose content is being packaged now have an incentive to package it them= selves
  • EKR - they need a mechanism to pickle TL= S transactions
  • Jeffrey Yasskin - presented evi= dence that users want to share apps
  • Rich Salz- = =E2=80=9Cnot much worry=E2=80=9D is overly positive. People were concerned.=
  • Dan York - my takeaway: some people are lookin= g for a discoverability thing, a common format to get your content to distr= ibutors. Others want availability (p2p, caching). =C2=A0

<= p class=3D"gmail-c6" style=3D"margin:0px;font-size:11pt;font-family:Arial;p= adding-top:0pt;padding-bottom:0pt;line-height:1.15">Charter Discussion

  • Jeffrey Yasskin - iden= tified a few essential use-cases and some opportunistic ones
    • Esse= ntial
    • Signed - P2P sharing and privacy preserving prefetch
      • Unsigned - user created untrusted web page
    =
    • Opportunistic
    • <= span class=3D"gmail-c3" style=3D"vertical-align:baseline;font-size:11pt">Si= gned as HTTPS - =C2=A0to avoid censorship
    • Sign= ed - books, security review, cross-CDN serving, Signature based SRI<= /li>
    • Unsigned - faster subresource loading, archive,
    • Dan York - =E2= =80=9Cdiscoverability=E2=80=9D - getting into distribution platform to repl= ace proprietary formats
    • Daniel Kahn Gilmore - S= ame as =E2=80=9Cprivacy preserving prefetch=E2=80=9D
    • Jeffrey - depends on which hop is involved. PPP is from client to c= ache and discoverability if from cache to server
    • Dan - Not really
    • Jeffrey - another use case = =E2=80=9Cencrypted caches=E2=80=9D - cache can hold non-public info<= /li>
    • Ben Schwartz - creating widely-shared secrets is not g= reat. If you don=E2=80=99t have many users, that=E2=80=99s not interesting.= If you do, the key is widely shared. Interested in TLS forwarding design t= hat would also resolve the privacy preserving prefetch
    • I do think= the use case is interesting, but not by encrypting the cache content
    • DKG - a differen= t argument, separable from the rest so people can work on that as a differe= nt 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. window= s updates. Need to restore that.
    • Alissa Coope= r (Cisco) - useful for content that=E2=80=99s not widely shared, as it can = save bandwidth in some scenarios
    • Zaheed Sarke= r (Ericsson) - blind caching has many benefits, so would be good to revisit= these use cases. We should look into this.
    • Bri= an 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 =E2=80=A6..
    • Ted - Dan wanted to create a si= ngle format. Can we decouple the signing from that format?
    • Mike Bishop - had a slide about adding a RTT to get something t= o 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.
      • <= li class=3D"gmail-c0" style=3D"font-size:11pt;font-family:Arial;margin-left= :36pt;padding-top:0pt;padding-left:0pt;padding-bottom:0pt;line-height:1.15;= text-align:left">Ben Kaduk (Akamai) - changing from transport to object is a= good way. But claiming the object is confidential will require thinking, a= s there are many side channels
    • Brian - not easy= to do but easy to separate. From a project planning standpoint - tying tog= ether 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 d= ependency 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 ha= rd problem
    • Ted - Even if all the content is pub= lic, 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. I= f you want to design this so that publishers have a very strong reason to d= o this, you need to design this while considering the incentives. Publisher= s need to opt-in to a system where a random cache can serve their content. = Forward caching failed because people didn=E2=80=99t know whether to trust = the quality of the cache. It=E2=80=99s a large hairy ball of a problem.
    • Kenji - Nothing that prevents JS or data fetches f= rom the server
    • DKG - I think mnot said that pu= blishers won=E2=80=99t participate unless they get metrics from users, and = encryption mechanism are not about preventing a ping back
    • Mnot - they=E2=80=99d want to make sure content is served fast, = available, integrity-protected, generally good UX. =C2=A0want to know how m= uch was served, but not a lot of metrics. so more about quality of experien= ce, unless we have something better than forward proxies. Publishers don=E2= =80=99t want to think about that. Roberto Peon has a proposal (proxy.pac?) = that can offer a better UX here. But it=E2=80=99s not =E2=80=9Cif we build = it they will come=E2=80=9D
    • Wendy Selzer - appre= ciate focusing on fewer use-cases as the core. it=E2=80=99s helpful to focu= s, rather than grow something that=E2=80=99s big and complex and serves non= e of the use cases very well. helps think about the threat model, etc. more= clearly.
    • Spencer (UW) - incentives align. Peop= le going to TLS, but TLS is also used for content that=E2=80=99s not really= secret. There=E2=80=99s a world of websites that use TLS just to ensure in= tegrity
    • Jeffrey - none of the proposal is for d= iscovery
    • Mnot - a lot of secondary use-cases, b= ut I don=E2=80=99t think we should say much about them. not a fan of =E2=80= =9Chope-based standardization=E2=80=9D. Should focus on the core use-case. = Opportunistic use-cases should be buried in an appendix with a large warnin= g
    • EKR - the use case of P2P sharing is required= . Want to push back on the notion that websites use TLS for integrity. Ther= e=E2=80=99s a reason we enforce integrity cypher suites and why we think co= nfidentiality is important (they=E2=80=99re hard to reason about, and users= want confidentiality even if pubs don=E2=80=99t). =C2=A0click-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=E2=80=99s. Web sites operators don=E2=80=99t ca= re about confidentiality, but users do. User expectations are not met today= =E2=80=9Cbecause the web is a rolling privacy nightmare=E2=80=9D. But it w= ould be nice to meet some of them. Brian=E2=80=99s point about moving from = transport to object is great. Binding the object model into the HTTPS origi= n scares me. I don=E2=80=99t understand all of the web. Much of the web=E2= =80=99s 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 s= ecurity.
    • 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 some= where else doesn=E2=80=99t seem too complex to reason about. It=E2=80=99s w= ork 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=E2=80=99t be a pr= econdition to starting the WG.
    • Mnot - is that a= gating factor?
    • Brian - Not a gating factor, bu= t 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 e= ncrypted caching system requires tracing where the key=E2=80=99s been and h= ow it moves. potentially very many actors involved in key distribution.
    • MT - To go back to user expectations of privacy. T= here=E2=80=99s 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 ab= out, 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 u= ntil this point I=E2=80=99ve been ambivalent about this, and this tips the = point. It creates a new surface area for security issues. Up until now I wa= s fairly confident that we=E2=80=99re not making things much worse, but thi= s change that.
    • Ted: Interesting to think of si= de-meetings as dystopian selection mechanisms. I don=E2=80=99t think we hav= e that much power to choose our dystopia, or else I wouldn=E2=80=99t get ou= t of bed in the morning. =E2=80=9Clet=E2=80=99s make sure we keep current d= ystopia=E2=80=9D. We can however understand our current model. Click tracki= ng is a good example. We were talking about a mechanism to change security = properties from transport to origin. But the mechanisms were also a combina= tion of transport and application (headers). So we have to take the pieces = from both transport and headers to move it here. That=E2=80=99s why we=E2= =80=99re talking about signed exchanges and not a mime type that does the s= ame. =E2=80=9CSecured by a combination of an object and its origin, where o= rigin doesn=E2=80=99t require transport=E2=80=9D-ish=E2=80=A6
      • EKR - Agree with Ted. Currently security model is a 5-10 yea= r attempt to construct something out of an even worse dystopia. Almost unde= rstandable now, but it=E2=80=99s 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 qu= estions people think need answering
    • Mnot - star= t to form an opinion that this will be two BoFs, we need indication from Ar= ea Director. A BoF in Singapore would draw out questions that ADs need to a= nswer and then we do a. . second one
    • Rich - say= ing =E2=80=9Cno=E2=80=9D is not a waste of time; it=E2=80=99s scientific me= thod. Also, Asia gets less attendance, so better participation if it=E2=80= =99d be North America based...
    • Ben Schwartz - m= y impression is that there are different people with different use cases, e= ach 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 w= eb 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=E2=80=99re already effe= ctively having a BoF, with a very constructive discussion. Let=E2=80=99s go= for a BoF, and maybe we=E2=80=99d need to do this twice e.g. to narrow sco= pe. Also, if not in Singapore, it won=E2=80=99t be my problem. (so don=E2= =80=99t delay till Vancouver)
    • Alissa Cooper: Ag= ree this is far more mature than most things we receive more most BoFs and = WGs. There=E2=80=99s a lot of people who would be interested in that and ar= e 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 w= orkshop: more detailed questions about web security model; publishers don= =E2=80=99t have a nuanced view on them.
    • You can= get input from publishers on the list for higher level questions, and that= =E2=80=99s fine
    • Mnot: agree. Publishers won=E2= =80=99t 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 wou= ld be a huge effort, so it=E2=80=99s 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 ques= tion is scoping and what we should focus on. Because there were so many use= -cases we discussed.
    • Ben Kaduk - Heard interest= ing and important questions, but questions that don=E2=80=99t need to be an= swered before a BoF. But we need to recognize that these open questions can= end up in a =E2=80=9Cno=E2=80=9D
    • Sam - propo= sed non-goals?
    • Jeffrey - encrypted caches, mat= h mesh
    • Jeffrey - heard strong advice to go for = Singapore, so will start working on a draft charter
--00000000000018e448058e60d115--