From nobody Tue Jul 9 07:41:56 2019 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 97566120440 for ; Tue, 9 Jul 2019 07:41:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.126 X-Spam-Level: X-Spam-Status: No, score=-0.126 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.247, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.249, HTML_MESSAGE=0.001, PDS_NO_HELO_DNS=1.295, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no 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 Mi17zDnkTWEb for ; Tue, 9 Jul 2019 07:41:52 -0700 (PDT) Received: from mail-ot1-f50.google.com (mail-ot1-f50.google.com [209.85.210.50]) (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 8A83612042D for ; Tue, 9 Jul 2019 07:41:52 -0700 (PDT) Received: by mail-ot1-f50.google.com with SMTP id z23so20143647ote.13 for ; Tue, 09 Jul 2019 07:41:52 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=oYhRHzV042g4dwMYcTuSKGNboMRUI7F8ut/ggR3X9B0=; b=tQzkdTzr6SHNuqRhfJ5MT/FJU+V1mx32K5xD83WmkWIXBF4yMlezc+pt9JGOIPDlDk VaLw//bW/oK2DKGxCQbY3XpEkWdA1RbOZcqHW2TbR+s6p8NSNccMDe+CD88fnNap7zBt iGYdvKh+DGy0GKj/CAeqVMu4O1Y30vA16LT7GoNBQ8pA/ORG7N0RbR1wPQnsKT7u/ZqW aON/rA3H4/eXtUSHOOJPOZhKdDLNYHuEJGk1MImQKXPHoP4/+qamKNasph1AhyA9bjWM jVUhajb9kDfCl5vvCvGTVCybwcFH526XI860J14ReDF91Uq0mkL3MoFDXPkUEyfdYR0t XdLQ== X-Gm-Message-State: APjAAAVxBoAI/4mmR9o3Pvt0saaLkSm6SBui8Ss74vnqptXFfAaqMjS2 ClcVqH791zpz/DTDkgJsis1/00DZgNid14duv/c= X-Google-Smtp-Source: APXvYqxnUuHkhjxBfdifn2lH8wsToeEQJ+kNHKQ6Ckrpxery5fLy0voSeETlJghlBdQf+8VuzhybFibWZuRet2j/p04= X-Received: by 2002:a05:6830:1206:: with SMTP id r6mr19713428otp.37.1562683311512; Tue, 09 Jul 2019 07:41:51 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Phillip Hallam-Baker Date: Tue, 9 Jul 2019 10:41:40 -0400 Message-ID: To: Jeffrey Yasskin Cc: wpack@ietf.org Content-Type: multipart/alternative; boundary="000000000000addf8f058d408f17" Archived-At: Subject: Re: [Wpack] WPACK side meeting at IETF105 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, 09 Jul 2019 14:41:55 -0000 --000000000000addf8f058d408f17 Content-Type: text/plain; charset="UTF-8" I have a packing technology that supports all the traditional capabilities of ZIP (incremental updates, compression) plus new cryptographic capabilities that are currently unique. The two packing scenarios that are relevant to escape type considerations are use as a software distribution format (it has Merkle tree authentication) and to support confidentiality (incremental and threshold encryption are supported). Threshold encryption is important in my view because most of the data breaches we are seeing today are breaches of data at rest. Existing CRM systems that are sold are based on the Ford-Wiener key release scheme which works for DRM because it isn't a confidentiality problem. The contents of the Lord of the Rings movie are not confidential, the concern is preventing onward distribution. With threshold encryption, the private key is split in two so the cloud service does not have the ability to decrypt the document by itself. If the key is split into n pieces, it takes n breaches. I submitted this as Internet Drafts but they are written according to the new HTML with diagrams format which is not yet supported by the IETF tooling. My tooling supports it so I recommend reading the document version here: http://mathmesh.com/Documents/draft-hallambaker-mesh-dare.html http://mathmesh.com/Documents/draft-hallambaker-mesh-cryptography.html On Fri, Jun 28, 2019 at 7:30 PM Jeffrey Yasskin wrote: > I'd like to schedule a time for this group to chat about the state of web > packaging in Montreal. We'll have just finished the ESCAPE workshop ( > https://www.iab.org/activities/workshops/escape-workshop/), and I can > discuss the progress in the specifications and Chromium's implementation. > > Would anyone have trouble attending the 8:30-9:45am slot on Tuesday > ? > > I'd also like to invite folks from this group to present their thoughts on > the subject. Let me know if you want time and how much, and I'll put an > agenda together. > > Thanks, > Jeffrey > _______________________________________________ > Wpack mailing list > Wpack@ietf.org > https://www.ietf.org/mailman/listinfo/wpack > --000000000000addf8f058d408f17 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I h= ave a packing technology that supports all the traditional capabilities of = ZIP (incremental updates, compression) plus new cryptographic capabilities = that are currently unique.

The two packing scenarios that are relevant to escape type considerations= are use as a software distribution format (it has Merkle tree authenticati= on) and to support confidentiality (incremental and threshold encryption ar= e supported).
<= /div>
Threshold encry= ption is important in my view because most of the data breaches we are seei= ng today are breaches of data at rest. Existing CRM systems that are sold a= re based on the Ford-Wiener key release scheme which works for DRM because = it isn't a confidentiality problem. The contents of the Lord of the Rin= gs movie are not confidential, the concern is preventing onward distributio= n.

With threshold encrypt= ion, the private key is split in two so the cloud service does not have the= ability to decrypt the document by itself. If the key is split into n piec= es, it takes n breaches.

= I submitted this as Internet Drafts but they are written according to the n= ew HTML with diagrams format which is not yet supported by the IETF tooling= . My tooling supports it so I recommend reading the document version here:<= /div>

http://mathmesh.com/Docum= ents/draft-hallambaker-mesh-dare.html
http://mathmesh.com/Documents/draft-hall= ambaker-mesh-cryptography.html



On Fri, Jun 28, 2019 at 7:30 PM Jeffrey Yasskin <= ;jyasskin=3D40google.com@dma= rc.ietf.org> wrote:
I'd like to schedule a time for this group = to chat about the state of web packaging in Montreal. We'll have just f= inished the ESCAPE workshop (https://www.iab.org/activities/wo= rkshops/escape-workshop/), and I can discuss the progress in the specif= ications and Chromium's implementation.=C2=A0

Would = anyone have trouble attending the 8:30-9:45am slot on Tuesday?

I'd also like to invite folks from= this group to present their thoughts on the subject. Let me know if you wa= nt time and how much, and I'll put an agenda together.
Thanks,
Jeffrey
_______________________________________________
Wpack mailing list
Wpack@ietf.org
https://www.ietf.org/mailman/listinfo/wpack
--000000000000addf8f058d408f17-- From nobody Tue Jul 9 15:34:04 2019 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 0DD1212006D for ; Tue, 9 Jul 2019 15:34:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, 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=mnot.net header.b=Ybiq03aV; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=lBWlRWrQ 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 HVDi25BHR36S for ; Tue, 9 Jul 2019 15:33:59 -0700 (PDT) Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com [66.111.4.27]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4F2DB1200F9 for ; Tue, 9 Jul 2019 15:33:59 -0700 (PDT) Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.nyi.internal (Postfix) with ESMTP id 1551E21B84; Tue, 9 Jul 2019 18:33:58 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute3.internal (MEProxy); Tue, 09 Jul 2019 18:33:58 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mnot.net; h= content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; s=fm3; bh=w xVKxoOd55aNSghuQC8O/Li07y37yefmSPzFtCrbSak=; b=Ybiq03aVnjRztmfbs s5JSfJXVoVG9wfsoQCxPkd57ivDwzLh0UL7quToV/wNtGhnZUjs+AGYoGPp9FJyv 3FnvHKO61Jioa55jGI9TQ+VC0hbSSfUc+FTSI/+XA4BdLaREsmeDvsVOe+Fjfr4y YmJufXDbjiEViaD8t8yXu0Ne0BXE817yk668YF9RYRAm/DgfNdrL7EdUTZOyTbC/ ZH87rI3lledq1wNgcBC1RKA24slvreERiumwEoFtkE2OURPEJgQRM0eGu+o8ybTh SskQ+LIZ/VLuv5N4165d+LYrD6FkTq11KrfLe5SXS2S4HjHue0V7P7v454fHgSLf oqE5w== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm3; bh=wxVKxoOd55aNSghuQC8O/Li07y37yefmSPzFtCrbS ak=; b=lBWlRWrQSPqadAl6ykRy2C1ZM8djRDvCTO3f4fsKW66sXX3PuL7EYoGVl MacT1056HOka1j8NKdE4DtXrYOTsHTD3/XPYbScFx0X5S9sidJVpOBLTkTcGBklR QGWfJ1T4ZB3WpdEvH8dShNkAEORP6Rm+2v1rw8Z2h5nIV4sLzzAVNvz99wz0sILm FkHvziaHungsMIcPK6IpdIv6ZWoJjcIhcThZhndNj0kVhhzIORULY7H5RnhR/ybZ mJNw7t9jSvvtNGowU/ONfTcmcxAWeYm1z0014uJZy/U3eIqhZJJ2NbEr7WHvzaqZ gnEGl9xt0UhSFatqRlk13v0qbimzw== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduvddrgeeggddutdcutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecunecujfgurheptggguffhjgffgffkfhfvofesthhqmh dthhdtvdenucfhrhhomhepofgrrhhkucfpohhtthhinhhghhgrmhcuoehmnhhothesmhhn ohhtrdhnvghtqeenucffohhmrghinhepihgrsgdrohhrghdpihgvthhfrdhorhhgpdhmnh hothdrnhgvthenucfkphepudeggedrudefiedrudejhedrvdeknecurfgrrhgrmhepmhgr ihhlfhhrohhmpehmnhhothesmhhnohhtrdhnvghtnecuvehluhhsthgvrhfuihiivgeptd X-ME-Proxy: Received: from macbook-pro.mnot.net (unknown [144.136.175.28]) by mail.messagingengine.com (Postfix) with ESMTPA id 21E26380074; Tue, 9 Jul 2019 18:33:54 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) From: Mark Nottingham In-Reply-To: Date: Wed, 10 Jul 2019 08:33:51 +1000 Cc: wpack@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Jeffrey Yasskin X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: Re: [Wpack] WPACK side meeting at IETF105 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, 09 Jul 2019 22:34:02 -0000 +1, Sounds good to me and blocked on my calendar.=20 FWIW there's a HTTP Priorities side meeting that's coalescing on = Wednesday in the same slot, and I suspect a few folks will want to go to = both, so Tuesday is (for now) good. Cheers, > On 29 Jun 2019, at 9:29 am, Jeffrey Yasskin = wrote: >=20 > I'd like to schedule a time for this group to chat about the state of = web packaging in Montreal. We'll have just finished the ESCAPE workshop = (https://www.iab.org/activities/workshops/escape-workshop/), and I can = discuss the progress in the specifications and Chromium's = implementation.=20 >=20 > Would anyone have trouble attending the 8:30-9:45am slot on Tuesday? >=20 > I'd also like to invite folks from this group to present their = thoughts on the subject. Let me know if you want time and how much, and = I'll put an agenda together. >=20 > Thanks, > Jeffrey > _______________________________________________ > Wpack mailing list > Wpack@ietf.org > https://www.ietf.org/mailman/listinfo/wpack -- Mark Nottingham https://www.mnot.net/ From nobody Fri Jul 19 07:45:33 2019 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 0348F1203BC for ; Fri, 19 Jul 2019 07:45:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=hughes.com header.b=UnJpj8mk; dkim=pass (1024-bit key) header.d=hughes.com header.b=OUbUcC2I 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 QfxiHFFWdYFw for ; Fri, 19 Jul 2019 07:45:29 -0700 (PDT) Received: from mx0a-00115402.pphosted.com (mx0a-00115402.pphosted.com [148.163.150.3]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 114041203C1 for ; Fri, 19 Jul 2019 07:45:29 -0700 (PDT) Received: from pps.filterd (m0118426.ppops.net [127.0.0.1]) by mx0a-00115402.pphosted.com (8.16.0.27/8.16.0.27) with SMTP id x6JEg085031499 for ; Fri, 19 Jul 2019 14:45:28 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hughes.com; h=from : to : subject : date : message-id : content-type : mime-version; s=3152018; bh=HL4gvO+/bQAy4ZHDSGAam42249H1j90PU6Wgp5LH7KQ=; b=UnJpj8mkPZffF9+/xm91BruEmP24D6DiiDQCzFO3/L7PgpeIT8w6U/5XZBqhMbd7Y6tA k8bJ4Rv8ngGNyYF9UrnJuw0SvCpwszEvvUJO6QYhE8NfEWGFees3TxjC5pTOPYQXhSnP v27+/r0kOh5667sN+jgMzVVELE5JBuFII/hEHAyNNN9AuP5YurFxlndZVe4F1wvY79nr EU4ffxVau8N1BibW2YYc3uvuswuqMpY9YwFlZb9wrHZKmBrtb9E07y6lAPIOCvZoG11a 1AtWoR/iaJQ+fU5jtvQQdUnLlW0q3EzPQ0UY94S2GmitKkGwtvrjQIXwxgcWGq5PjdOH eA== Received: from nam01-sn1-obe.outbound.protection.outlook.com (mail-sn1nam01lp2055.outbound.protection.outlook.com [104.47.32.55]) by mx0a-00115402.pphosted.com with ESMTP id 2tufsqg1e7-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT) for ; Fri, 19 Jul 2019 14:45:28 +0000 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=JTjH/05YtuisIzuW4cx0Ik3D+S6yPL4N/rH1Azd3dqHD2FnQoE9UscK6eR4SC4wnXsPeLQ8vFSX9yi9rlAnV4OH9/nh52fFIx4ZjagrMutWcAb4/zGVIxe4AE+eaovjZplI1w3dftee/iReLJ5BLg1zJwq7iiGXxR7rUUNx5nzWP8PYAXmrzzN8wBJ3B3qavHtjgqZW69HzkVcsOuhXo12u2lnPQy1OJUc7RREcW7ClYeV+5MFbqEpF7gZklByfi4zSnVFM4UobJcNrM1SgPIqryCXxvgB1lkdxe29eikW3Fczdfh+mU7f/b4PMOJ1HekWmFQACqjqaVIvnNbsuR4g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=HL4gvO+/bQAy4ZHDSGAam42249H1j90PU6Wgp5LH7KQ=; b=H6s/aGmJ0wMTatsQtslk63GJ6HBjNZImk7q7WAI/f4iRGpoaPgZGeC1OKhy4O5rgk4IOyTZxZa3EYb6DrtiLgxbZWUGdb7Tz6zqzOMPaaE8eqbtmiU8tzmfpigyXLrodRgdNvkZqpw9WK0f5zuqEUH6eNADxnHswO6mKO20/B/GdPlWFL8vzisTg3xgETG+wTcLwhSbEvbXVx80K+hJ5G6KII7g8ql8MVGCYQNIFGaHjFxTM4tYQxqbFKl7MioWtHaOSByxzI6HGLJATLkxZlprfv9awm0QT0bguw+IWLZxxeOfraXuxj3Z+UuF7Y6kEpfkh/nOLa4mzVy6Y355KBw== ARC-Authentication-Results: i=1; mx.microsoft.com 1;spf=pass smtp.mailfrom=hughes.com;dmarc=pass action=none header.from=hughes.com;dkim=pass header.d=hughes.com;arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hughes.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=HL4gvO+/bQAy4ZHDSGAam42249H1j90PU6Wgp5LH7KQ=; b=OUbUcC2IlvU/NrYUQUVH1xj+v6svOA0sSvtPdnfyxclTebDclYWecZFWC1mXJzH1udOIt8sAQ/sNW/B9xV+ubjdzdctGtE0rUowzfStVZ/Lk7UjeYX85fekN/Jz8a0ZCHruQE4tm9tNdP8BzDOd55sf20MoVcy3iWETgXCC8VTg= Received: from BN6PR11MB1459.namprd11.prod.outlook.com (10.172.21.22) by BN6PR11MB1345.namprd11.prod.outlook.com (10.173.32.145) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2073.14; Fri, 19 Jul 2019 14:45:24 +0000 Received: from BN6PR11MB1459.namprd11.prod.outlook.com ([fe80::10e9:8f1e:1547:980f]) by BN6PR11MB1459.namprd11.prod.outlook.com ([fe80::10e9:8f1e:1547:980f%11]) with mapi id 15.20.2073.015; Fri, 19 Jul 2019 14:45:24 +0000 From: "Su, Chi-Jiun" To: "wpack@ietf.org" Thread-Topic: missing piece for use of wpack for satellite caching Thread-Index: AQHVPkAPAjXDTI7YLUiLLXHWQYHmvw== Date: Fri, 19 Jul 2019 14:45:23 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [173.38.117.82] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: f2d81e09-1296-45a2-37af-08d70c57bb66 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600148)(711020)(4605104)(1401327)(2017052603328)(7193020); SRVR:BN6PR11MB1345; x-ms-traffictypediagnostic: BN6PR11MB1345: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-forefront-prvs: 01039C93E4 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(136003)(39860400002)(366004)(396003)(376002)(346002)(189003)(199004)(52536014)(6436002)(66476007)(76116006)(66946007)(66066001)(99286004)(71200400001)(64756008)(2501003)(8936002)(86362001)(476003)(66446008)(5660300002)(66556008)(486006)(19627405001)(316002)(2351001)(66574012)(71190400001)(2906002)(6916009)(7696005)(25786009)(14454004)(54896002)(6116002)(33656002)(3846002)(74316002)(81166006)(478600001)(9686003)(105004)(6506007)(7736002)(55016002)(5640700003)(102836004)(26005)(1730700003)(256004)(561944003)(68736007)(53936002)(186003)(81156014)(8676002)(4744005); DIR:OUT; SFP:1102; SCL:1; SRVR:BN6PR11MB1345; H:BN6PR11MB1459.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: hughes.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: YrwrwLc6E7QPLzAmquhC9H3gnzzpADq0pVg5hJbV7qflZtHfkAl/kEs/j1DBQgCHWdvu2035E4khLhtB9Rq+gDHx/F9995KwElQRuCZlqZp6nFXiJd08gsPVJ1ZEdS4PH/xcamf/5w3cnEtYXGGdvwQWNEQZ+VNsK8GWDMDk6mwyKzUKeypC3F4Ks/qoG/bey5SBozpj7+T+/sx/a9aqPfpNZdkZXCGHn2j1Ll50AqDUN6T70p+dAD3H04aVaugzvaWNqqxuN+Hpl3Qlx1OXY78FzBqSnF9zcyosjd93LkX4x5/mOBatfPEMYvviIg/kNe7P5LKp/b5rRDwJ26SmCxHpKGdSaAeXE9T1X+WauIz9z2MXWG8YuWCB4vQaSjzN+VJOkjqNUZ33rORfY321TXPlznyv4YB0qTrqbhlgAJw= Content-Type: multipart/alternative; boundary="_000_BN6PR11MB1459A24B2AEE261693A7168FCECB0BN6PR11MB1459namp_" MIME-Version: 1.0 X-OriginatorOrg: hughes.com X-MS-Exchange-CrossTenant-Network-Message-Id: f2d81e09-1296-45a2-37af-08d70c57bb66 X-MS-Exchange-CrossTenant-originalarrivaltime: 19 Jul 2019 14:45:23.9761 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 0e1f3187-4610-4ce2-bad1-b92f4ba36ab3 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: Chi-Jiun.Su@hughes.com X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN6PR11MB1345 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-07-19_10:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=496 adultscore=3 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1810050000 definitions=main-1907190161 Archived-At: Subject: [Wpack] missing piece for use of wpack for satellite caching 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: Fri, 19 Jul 2019 14:45:31 -0000 --_000_BN6PR11MB1459A24B2AEE261693A7168FCECB0BN6PR11MB1459namp_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, In current wpack proposal, there is no cache discovery mechanism. In the case of community wifi via a satellite system, a wifi router is conn= ected to a satellite terminal which is talking to a satellite to go to the = internet. All user devices are connected to the satellite terminal via wifi= . The satellite terminal prefetches popular web page bundles opportunistica= lly and store them in the cache inside the terminal. The cache is on-path f= or user agents to go to the internet. The user agents do not know the exist= ence of the on-path cache and the agent will go to the internet when a user= type a url even though the web page is already in the terminal cache. One approach is to explicitly configure user agents to fetch the page from = the on-path cache. Squid explicit proxy can be one of the existing approach= es? Do we have approaches to let us explicitly configure user agents to point i= t to the cache? any suggestions? thanks. cj --_000_BN6PR11MB1459A24B2AEE261693A7168FCECB0BN6PR11MB1459namp_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi,

In current wpack proposal, there is no cache discovery mechanism.

In the case of community wifi via a satellite system, a wifi router is= connected to a satellite terminal which is talking to a satellite to go to= the internet. All user devices are connected to the satellite terminal via= wifi. The satellite terminal prefetches popular web page bundles opportunistically and store them in the cache ins= ide the terminal. The cache is on-path for user agents to go to the interne= t. The user agents do not know the existence of the on-path cache and the a= gent will go to the internet when a user type a url even though the web page is already in the terminal cach= e.

One approach is to explicitly configure user agents to fetch the page = from the on-path cache. Squid explicit proxy can be one of the existing app= roaches?
Do we have approaches to let us explicitly configure user agents to po= int it to the cache?
any suggestions?

thanks.
cj
--_000_BN6PR11MB1459A24B2AEE261693A7168FCECB0BN6PR11MB1459namp_-- From nobody Sun Jul 21 18:07:25 2019 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 30586120090 for ; Sun, 21 Jul 2019 18:07:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=isoc.org 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 1qrLlKbCjgVm for ; Sun, 21 Jul 2019 18:07:20 -0700 (PDT) Received: from NAM03-DM3-obe.outbound.protection.outlook.com (mail-eopbgr800081.outbound.protection.outlook.com [40.107.80.81]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3FA16120075 for ; Sun, 21 Jul 2019 18:07:20 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=D93nddvWKhRTz4gJO1mgtde14hFze4SRQuSN+5GW9nmfuyDa6oEaDNR+9+TkqVSBEISnnhx9rr9Wu87iu14ysKKKAZN0Lb+OMPqwGQjDzL/kR+MUtfa1w9h+SNXlxuFvMOZkriR15X7qjUeuAc1nQAtXvTVmtLQH12Me6fBqbEhhrRDE6SteUsSezH9gHJta6uZotm7U8EJPuxDzyGSxyhDsng0alYtxaZEVrfsDfRbLTLXntdkT2MTdigOdMOLgZJcdnzNfGkCKESASoE7ekZtdZa87EyW6RquKpsPgjrqnIhSM2U70yiPOfPpGPBiBg2JDQeddqk4yv2rY9W2s8g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=bOXn2DM9rdLLmcfTGUE2tba0+4KP74Z/NyOPjbPsRx8=; b=H/NgkvUiiMJiqm7HuPgBqLXXJwHbwhiAQPRo7HJFymOP92Bq0gDZPRUutZZ/oORY7tvwu7MssUHzD426Aec8E6Kh96VYt3+NbUSeRCCNO1fcpm8Qe3zbA8C1iF8tVyZ0cQ4IbabgKBf/XkpJ3UTzFI+YZMj1wgMoyNt2dg0wKz7u2IL4jC+MW2mIFJdrnxtaUI2eWu2hRHM15YT7+5ZKCRP4up4UDg+QLw4mN9aX4cfz9ab1umofjxlicIngCJ3dldQ/9hlI7ZwEIW1CCGPRELRhxQto/rIZf9F1+63vQTA5XtY3PXPJo2pFqZd/AcmHhsrcoeevVAo/lIaxcYZfiA== ARC-Authentication-Results: i=1; mx.microsoft.com 1;spf=pass smtp.mailfrom=isoc.org;dmarc=pass action=none header.from=isoc.org;dkim=pass header.d=isoc.org;arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isoc.org; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=bOXn2DM9rdLLmcfTGUE2tba0+4KP74Z/NyOPjbPsRx8=; b=1AP8DxXOB/MxYpGxGUsB0A35RmMa6xv7q11n7C7agQmXP8HgvaIpl1pTvapaRu3TiM509dJzv9U/eYoFKE+6aHxykFYQepZMbq3jjJHDS10qUXPlJNhSZb6DetSWp0UuuAFGSH4BdF/v9jJlrQ4smWXbuF8DRpayMyN4hmnTIQU= Received: from BN8PR06MB5570.namprd06.prod.outlook.com (20.178.210.219) by BN8PR06MB5362.namprd06.prod.outlook.com (20.178.208.140) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2094.15; Mon, 22 Jul 2019 01:07:19 +0000 Received: from BN8PR06MB5570.namprd06.prod.outlook.com ([fe80::d1ec:89c9:f776:222]) by BN8PR06MB5570.namprd06.prod.outlook.com ([fe80::d1ec:89c9:f776:222%7]) with mapi id 15.20.2094.013; Mon, 22 Jul 2019 01:07:19 +0000 From: Dan York To: "wpack@ietf.org" Thread-Topic: Reminder - WPACK side meeting at 8:30am on Tuesday, July 23 in Van Horne Room Thread-Index: AQHVQCnPUUPIq6shD0iq49RwXu9FJA== Date: Mon, 22 Jul 2019 01:07:18 +0000 Message-ID: <26348E7F-496C-49DE-B0C2-41744790B4F3@isoc.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=york@isoc.org; x-originating-ip: [2001:67c:1232:144:3119:8c2a:7b4f:eecf] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: aa5702ea-f9fa-483d-7c52-08d70e40f19b x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600148)(711020)(4605104)(1401327)(2017052603328)(7193020); SRVR:BN8PR06MB5362; x-ms-traffictypediagnostic: BN8PR06MB5362: x-ms-exchange-purlcount: 1 x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:7691; x-forefront-prvs: 01068D0A20 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(346002)(396003)(376002)(136003)(366004)(39850400004)(53434003)(199004)(189003)(14454004)(6506007)(2616005)(1730700003)(99286004)(2906002)(2501003)(2351001)(102836004)(4744005)(186003)(8676002)(476003)(46003)(68736007)(81156014)(8936002)(33656002)(6116002)(316002)(81166006)(36756003)(71190400001)(71200400001)(966005)(6512007)(6306002)(5640700003)(5660300002)(91956017)(76116006)(66946007)(66446008)(66476007)(66556008)(64756008)(478600001)(256004)(14444005)(486006)(6486002)(86362001)(6436002)(7736002)(25786009)(53936002)(305945005)(6916009); DIR:OUT; SFP:1101; SCL:1; SRVR:BN8PR06MB5362; H:BN8PR06MB5570.namprd06.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: isoc.org does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: hm60yVq67ur46R4w31UDkxQe/Mt0ooghTXD4FP/Dux3L6E0Ox7gmlZx71yoWJmV41398xJqMDZVKTLqLH6COGStoWcOc0z0YWPakwP7+PdAhd/N1yGVwV1sfTQle1BcU/7Py47NCgjGSMqsO5m0WXQ1ajQCuEjgzlfOBYWRYfwscDNMQrregVeM73WseNUD3XF0DDCsHMrsvBEvwcSmz98QVmf6pz+N/mwH/o5ADGNGH47Pbg84FEaNEd+R3ePzsI/Sx5dhu8ZNsKYLPi64RaB/GctKrMAS4EOSygkOanVbVuLkfl+wX5C+fGotjCbfSKuSuHBY8MfMkvs3/OYzPmSq6VvdHRTQ+Y8A6l9wa3XbG1kyNzU3eV4pFJ7t+Jm58Va2bIiWXI25uN9B9bRCpmO4VKd7vOzVKaA0nzKqbkPY= Content-Type: text/plain; charset="us-ascii" Content-ID: <6D5564C9168DB14CB11C5225237BC123@namprd06.prod.outlook.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: isoc.org X-MS-Exchange-CrossTenant-Network-Message-Id: aa5702ea-f9fa-483d-7c52-08d70e40f19b X-MS-Exchange-CrossTenant-originalarrivaltime: 22 Jul 2019 01:07:18.9229 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 89f84dfb-7285-4810-bc4d-8b9b5794554f X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: york@isoc.org X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN8PR06MB5362 Archived-At: Subject: [Wpack] Reminder - WPACK side meeting at 8:30am on Tuesday, July 23 in Van Horne Room 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: Mon, 22 Jul 2019 01:07:23 -0000 Just a reminder that Jeffrey Yasskin has reserved the Van Horne room on Tue= sday, July 23, at 8:30am for a side meeting related to web packaging. The Van Horne room is on the 2nd floor. See the map - https://datatracker.i= etf.org/meeting/105/floor-plan#2nd-floor There is NOT any remote participation set up for the unofficial side rooms,= but if there ARE people who want to connect remotely, I could certainly se= t up a Zoom session. (Just let me know in advance.) Dan From nobody Mon Jul 22 06:02:44 2019 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 1F255120059 for ; Mon, 22 Jul 2019 06:02:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.251 X-Spam-Level: X-Spam-Status: No, score=-9.251 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.249, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_SPF_WL=-7.5] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=chromium.org 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 kG6Ir0hxBx8x for ; Mon, 22 Jul 2019 06:02:41 -0700 (PDT) Received: from mail-lj1-x232.google.com (mail-lj1-x232.google.com [IPv6:2a00:1450:4864:20::232]) (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 48CFF12001A for ; Mon, 22 Jul 2019 06:02:41 -0700 (PDT) Received: by mail-lj1-x232.google.com with SMTP id x25so37559271ljh.2 for ; Mon, 22 Jul 2019 06:02:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Im0LcxI3/i4C6XA6WKWUP+vt6EJiaaDj54ijATmrtRg=; b=gRWMQShACFrC8tf720w1rsdZsccM7NVR9D4rHGfrmnQmzl+pZYxy2F3hw+aqALsm88 YHwiGSidvFmNsXTjRTnh0fGXS5VMdk9enwwXw7zjWicldwjQplAFnTko8jARryZ1o7EA FLU28WcmwNX0VJvvnY3Jn2aAflH/PgOb1Ad8E= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=Im0LcxI3/i4C6XA6WKWUP+vt6EJiaaDj54ijATmrtRg=; b=eRct30jhGyfYFKVnBifAiaCyVLX6a375WsSaT8MkZi2maItM1i9h+WdSql2ajjMuag TcOlRUXfgnCvdVGfpd+HqjDwdIldtssoL+19Yz4qdVyI7KMoPR4d1mY99Mv3ppkc6900 75M6jWgpl8tvJ/ED2kR1dGbZ0p73m4osv1yJh0974iYhZR27psliaIAd3MFnQIZRId87 lcziRWogpIBxL5v/sH/riDd/QM5pO9fvaAOcj7MwdFUDGoanaqraP7+28YoQOL+FBnK0 j3Pi3Q6/7jnE8IzzSg6Vcf7xY5drIIgIFIRzF4/FRV14ygcuCVydJOtesgViRiDqDZzm h3Rg== X-Gm-Message-State: APjAAAWwsShJYWjCt3vSI/DLdaRHkyy2Nn7DgDUkDLaCHCFuyuiI1gnC 9wshfgi8Xswd7aG20f59tvROadRUlBgIrdTtDQnTkyZAE5Y= X-Google-Smtp-Source: APXvYqwNMpMeIB5Ur6fUJw1GnzHUWpaiBtH8tM1ue2+2+CVzN26hINI/PdQVjSfwjs+9ct3ecDGA7UjohzDba5D2T84= X-Received: by 2002:a2e:86c3:: with SMTP id n3mr37729592ljj.129.1563800558960; Mon, 22 Jul 2019 06:02:38 -0700 (PDT) MIME-Version: 1.0 References: <26348E7F-496C-49DE-B0C2-41744790B4F3@isoc.org> In-Reply-To: <26348E7F-496C-49DE-B0C2-41744790B4F3@isoc.org> From: Jeffrey Yasskin Date: Mon, 22 Jul 2019 09:02:28 -0400 Message-ID: To: Dan York Cc: "wpack@ietf.org" Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [Wpack] Reminder - WPACK side meeting at 8:30am on Tuesday, July 23 in Van Horne Room 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: Mon, 22 Jul 2019 13:02:43 -0000 Thanks for the reminder email! I sketched an agenda at https://github.com/WICG/webpackage/wiki/IETF-105-Agenda. If there's anything else you want to discuss, or if you have a presentation, let me know. Jeffrey On Sun, Jul 21, 2019 at 9:07 PM Dan York wrote: > > Just a reminder that Jeffrey Yasskin has reserved the Van Horne room on Tuesday, July 23, at 8:30am for a side meeting related to web packaging. > > The Van Horne room is on the 2nd floor. See the map - https://datatracker.ietf.org/meeting/105/floor-plan#2nd-floor > > There is NOT any remote participation set up for the unofficial side rooms, but if there ARE people who want to connect remotely, I could certainly set up a Zoom session. (Just let me know in advance.) > > Dan > > _______________________________________________ > Wpack mailing list > Wpack@ietf.org > https://www.ietf.org/mailman/listinfo/wpack From nobody Tue Jul 23 15:36:09 2019 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--