From nobody Wed Aug 5 07:34:25 2020 Return-Path: X-Original-To: sframe@ietfa.amsl.com Delivered-To: sframe@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CDC2A3A090F; Wed, 5 Aug 2020 07:34:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.102 X-Spam-Level: X-Spam-Status: No, score=-2.102 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, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.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 09M9_pKOZlBY; Wed, 5 Aug 2020 07:34:19 -0700 (PDT) Received: from EUR02-AM5-obe.outbound.protection.outlook.com (mail-eopbgr00060.outbound.protection.outlook.com [40.107.0.60]) (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 3A7563A0918; Wed, 5 Aug 2020 07:34:19 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=FqtyvYdqOQ7k80cTorwGp/2/mImgY0wCXuWfkYmVpoKGjLNcE9mKsy0twM2g8DOjiQSHI8p+JspUEJLBRnUWSCtEshA2V8Vecf1mzv8ZXjGB6Vm6FnfyCtnlZxQh6E4QyEbY2WnMUUeCyCPrbSnWSCXqPwb+6AHBOOz/3rzrCparENIXFpaV594yPptRbyyFLIxfFn+gmdM9fzvHfYX3gQYg5A8WGE8hcSGJRn/d7Yxh0D43DXovfx4KCPeQhrx+3aV1V28wYwn3Yc31wll7m8ska8FvDLoDivwoAjQitIvTA50pIPIPZDGncdbr787oO4VGtTO15HhInPNw5ztU2w== 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=9+K4nwNxPYxNiAot6mzXqjST9rr60fyDrX3NxibSU2M=; b=NrFjreN7oP5jj5VnhNJptU34EiDHrjh8dG/G+GkWfWcsEUCQXJMCJyqUgUmfmcoPjt0GpZfMRPcwodJo0tmWVBGI1APXuXMBnIQoU4JFvIobsVbwQilzAUsOUmnJ78gS3+Oe5efLpMsD4Fl/Tl3Xp+9c6DDy+pWffI3ilAN3iKbO/2vqhfqOPGbckQvPasVxlFKXQ2Zf6gU1vp8oksRL9y0JlHH3nXYnl1AOQJOOfHZooTgY4sbq6KTk+9epr9To/4vKtPadM4wp5qMOYmdZeJRR6aPSisePTFC43BOEiQ+GdDcL7KqN3g/onVScNwPQllK2kXi8vC5/rdNGeBAi/g== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=ericsson.com; dmarc=pass action=none header.from=ericsson.com; dkim=pass header.d=ericsson.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=9+K4nwNxPYxNiAot6mzXqjST9rr60fyDrX3NxibSU2M=; b=guzh30GU8DFGABcv8sJr+rFKIDdOxC63O3enkvlagk8QRcIp/16BpNWtBk9AJfttSDUClXa+5NzMFdQzZ1L4116BlJ+dnAl2eAX+0awyqyTDzI/3aOXL/Cnd489NdtYiJgZRwUClFJb+PQvW8qWmZJvqNct4oS5lslQWZ8dxW4Y= Received: from HE1PR0702MB3772.eurprd07.prod.outlook.com (2603:10a6:7:8e::14) by HE1PR07MB3097.eurprd07.prod.outlook.com (2603:10a6:7:32::31) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3261.16; Wed, 5 Aug 2020 14:34:13 +0000 Received: from HE1PR0702MB3772.eurprd07.prod.outlook.com ([fe80::d95a:be8:b97b:582d]) by HE1PR0702MB3772.eurprd07.prod.outlook.com ([fe80::d95a:be8:b97b:582d%5]) with mapi id 15.20.3261.016; Wed, 5 Aug 2020 14:34:13 +0000 From: Magnus Westerlund To: "ben@nostrum.com" , "rlb@ipv.sx" CC: "emadomara=40google.com@dmarc.ietf.org" , "dispatch@ietf.org" , "sframe@ietf.org" Thread-Topic: [dispatch] SFRame Next Steps (was Re: SFrame proposed WG charter) Thread-Index: AQHWZ16R4N9P2bY+DUCbQ3y9KXPWG6kpnDqA Date: Wed, 5 Aug 2020 14:34:13 +0000 Message-ID: References: In-Reply-To: Accept-Language: sv-SE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-mailer: Evolution 3.28.5-0ubuntu0.18.04.2 authentication-results: nostrum.com; dkim=none (message not signed) header.d=none;nostrum.com; dmarc=none action=none header.from=ericsson.com; x-originating-ip: [98.128.243.14] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: c678c91e-1ab8-4a75-bc04-08d8394c9fd1 x-ms-traffictypediagnostic: HE1PR07MB3097: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: Uq7DKu4IRCtE/7G4w7jYqWbKkq7ICsBuRQX7RdG5wWarXRmWhYATPL+SWieLV7idOPPkcHrRd4HN8z16hiJKsyOT4TmH6rpIiQmHjzHc9IVISky0ES0qZlxkKyEoBxGg1imxzvrJFLsGKFc6PtKMK0excSM1e1/28nGeInKAO+UAAl9JoBa8XUxXfsfdOhFE02iCJphO6GIibY3uuZTx5YVos7BmSsArdSzjRHkpuugGiVkWfpDXLwr3Nb++A7mEOlKQn9WHdVyCj2aKNp0sd7b6cvuFhc6EipFoRAo0+7WaGflaiANAcIjEdQkF+gX+ptFXyV66TVNZsYM/ECMI1N52+/t3ntKjy2NCTNaA7nohZowYrGNpGgDdqYnepykj4MYCHaa3tT60B3mdYzY0lhLed4XRo79l6QB7txorJCVLjYT/YdfV1QzmREDEMNSPtm8P62GS9dvKQcuBKx/fjw== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:HE1PR0702MB3772.eurprd07.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(136003)(376002)(396003)(366004)(346002)(39860400002)(66556008)(76116006)(5660300002)(2906002)(66946007)(66446008)(64756008)(66476007)(71200400001)(83380400001)(478600001)(966005)(6512007)(36756003)(186003)(6506007)(53546011)(8936002)(4326008)(110136005)(54906003)(316002)(2616005)(44832011)(6486002)(26005)(86362001)(8676002)(99106002); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: 3ACB0urKxUwBifblmjqFF+J88IZPMX02Qcf9Xuwf3IZFnvWutEfB3hGFsSO9prXJje09WgRsUILt2B2zzSBZD2XinVXYn89YMJy12HbZfXJbc0xD2ETNbcRLpiLZexWUChR7mjKk2Fgkrv0MSR0Hb5IqqUQm/BOVoyWqD/kXWj4RWGf0L7M0to01NiyPBzOfbuze8eMHhInXGqYhbiWonxm4pxNtKJ9heA24Far1dUtcHsUs1JhDzQdK5PbvfbfrHC+dAfN2DqvnE4Lg5GEItEJrpBk6a2E87a5VOXzXpd/Jg9Igy/+MKs63W9tz3rUz8bPxTCdxX9/3D8f5OOqf48oGGhWVplvClsnQozj8+qLUl+c0IMj3OKciDAU7vqUYrXWo3DFXDCruH6OYaZInMSFSI5YqDFYDXxtECYI5xqKJzEMlK6JMocWsBU66PHikRF2NMZ+cfIrH8hSzTlZz+kGBJrHk9Z0OITSG6NSMz4WfqffSIXEBh2PwIIyP+yfnaC49tl+UKDl/Hv/z1vB30wXpkQUA9+HIpPtz0Dml8an4UPv+EuKFHmMSETtSbPV4jlx73i0HaAP3Jn5P5qzxgk+9wGYP+xFGk2BnwthfxSYNlV+8ji6hqHBFmOZzeQ693BbDNT7vPvnIC/brwggXuw== x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: HE1PR0702MB3772.eurprd07.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: c678c91e-1ab8-4a75-bc04-08d8394c9fd1 X-MS-Exchange-CrossTenant-originalarrivaltime: 05 Aug 2020 14:34:13.2706 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: /dvB1EZLihYxLUM/ucmeUwd4UKWT1f3PLtEldbftK3peKUHC1hCPRnA1xtS5fWZWHHMThSEpcf6Hca361XaljwNSKIR1uWWnUBdfmELg4fg= X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR07MB3097 Archived-At: Subject: Re: [Sframe] [dispatch] SFRame Next Steps (was Re: SFrame proposed WG charter) X-BeenThere: sframe@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Aug 2020 14:34:21 -0000 SGksDQoNCkkgd2FudCB0byBtYWtlIG9uZSBoaWdoIGxldmVsIGNvbW1lbnRzIG9uIHRoZSBwcm9w b3NlZCBjaGFydGVyIGZvciBTRlJBTUUuIA0KDQpUaGUgY2hhcnRlciBhdHRlbXB0cyB0byBiZSB0 cmFuc3BvcnQgYWdub3N0aWMuIEhvd2V2ZXIsIHdlIGtub3cgdGhlcmUgYXJlDQpjZXJ0YWluIHVz ZSBjYXNlcyB0aGlzIHNvbHV0aW9uIG5lZWRzIHRvIHN1cHBvcnQuIEFuZCBJIHRoaW5rIG9uZSBv ZiB0aGUgaGFyZGVzdA0KZnJvbSBhIHNlY3VyaXR5IHBlcnNwZWN0aXZlIGlzIHRoZSBtdWx0aS1w YXJ0eSBjZW50cmFsaXNlZCBvbmUgd2l0aCBvbmUgb3IgbW9yZQ0KU0ZVcy4gQmFzZWQgb24gdGhl IHNpZ25pZmljYW50IGRpc2N1c3Npb24gd2UgaGFkIGluIFBFUkMgYXJvdW5kIHRocmVhdCBtb2Rl bCwgSQ0KdGhpbmsgdGhpcyBjaGFydGVyIGRvIG5lZWQgdG8gaGF2ZSBpbiBpdHMgZGVzY3JpcHRp b24gd29yayB0byBleHBsaWNpdGx5IGRldmVsb3ANCnRoZSB0aHJlYXQgbW9kZWwgYXMgd2VsbCBk ZXNjcmliZSB3aGljaCBhc3BlY3RzIG9mIHRoZSB0aHJlYXQgbW9kZWwgdGhhdCBvbmUgY2FuDQph ZGRyZXNzLiBGb3IgZXhhbXBsZSBJIHRoaW5rIHRoZSBzZWN1cml0eSB0aHJlYXQgb2YgbWVkaWEg ZGVsYXkgd2hpY2ggaXMgYW4NCmludGVyZXN0aW5nIHZhcmlhbnQgb2YgInJlcGxheSIgYXR0YWNr IHRoYXQgZXhpc3QgZm9yIHJlYWwtdGltZSBtZWRpYQ0KY29udmVyc2F0aW9uIHdoZXJlIHRoZXJl IGFyZSBsb2dpYyB0aGF0IHNlbGVjdHMgd2hhdCB0byBmb3J3YXJkLiANCg0KQ2hlZXJzDQoNCk1h Z251cyBXZXN0ZXJsdW5kDQoNCg0KT24gRnJpLCAyMDIwLTA3LTMxIGF0IDEzOjE1IC0wNDAwLCBS aWNoYXJkIEJhcm5lcyB3cm90ZToNCj4gVGhlIGxpbmsgRW1hZCBwb3N0ZWQgc2hvdWxkIGFsbG93 IGZvciBjb21tZW50cywgc28gcGxlYXNlIGZlZWwgZnJlZSB0byBjb21tZW50DQo+IGRpcmVjdGx5 IG9uIHRoZSBkb2MuDQo+IA0KPiBPciB5b3UgY2FuIHJlcGx5IHdpdGggY29tbWVudHMgaGVyZSBh bmQgd2UnbGwgZ2V0IHRoZW0gaW5jb3Jwb3JhdGVkLg0KPiANCj4gT24gVGh1LCBKdWwgMzAsIDIw MjAgYXQgNTo1OSBQTSBCZW4gQ2FtcGJlbGwgPGJlbkBub3N0cnVtLmNvbT4gd3JvdGU6DQo+ID4g SGkgZXZlcnlvbmUsDQo+ID4gDQo+ID4gV2UgaGFkIGEgZ29vZCBkaXNjdXNzaW9uIG9uIFNGcmFt ZSBpbiB0aGUgZGlzcGF0Y2ggbWVldGluZywgYW5kIGEgbG90IG9mDQo+ID4gaW50ZXJlc3QgaW4g cHJvZ3Jlc3NpbmcgaXQuIFRoZSBjaGFpcnMgd291bGQgbG92ZSBpdCBpZiB3ZSBjYW4gZ2V0IHNv bWUNCj4gPiBkaXNjdXNzaW9uIG9mIHRoZSBwcm9wb3NlZCBjaGFydGVyIChiZWxvdykgbm93LCB3 aGlsZSBpdOKAmXMgc3RpbGwgZnJlc2ggaW4NCj4gPiBwZW9wbGXigJlzIG1pbmRzLiBJZiB3ZSBk b27igJl0IHNlZSBmZWVkYmFjayB0byB0aGUgY29udHJhcnkgd2l0aGluIGEgY291cGxlIG9mDQo+ ID4gd2Vla3MgKGxldOKAmXMgY2FsbCB0aGF0IDE0IEF1ZyksIHdlIHdpbGwgaGFuZCBpdCBvdmVy IHRvIHRoZSBBUlQgQURzLg0KPiA+IA0KPiA+IFRoYW5rcyENCj4gPiANCj4gPiBCZW4uDQo+ID4g DQo+ID4gPiBPbiBKdWwgMjcsIDIwMjAsIGF0IDEyOjM0IFBNLCBFbWFkIE9tYXJhIDwNCj4gPiA+ IGVtYWRvbWFyYT00MGdvb2dsZS5jb21AZG1hcmMuaWV0Zi5vcmc+IHdyb3RlOg0KPiA+ID4gDQo+ ID4gPiBIaSBkaXNwYXRjaCwNCj4gPiA+IA0KPiA+ID4gRm9sbG93aW5nIHVwIG9uIHRoZSBkaXNj dXNzaW9uIHdlIGhhZCB0aGlzIG1vcm5pbmcgaW4gSUVURiAxMDggZGlzcGF0Y2gNCj4gPiA+IHNl c3Npb24gYWJvdXQgU0ZyYW1lLCBpdCBzZWVtcyB0aGVyZSBpcyBlbm91Z2ggaW50ZXJlc3QgdG8g Zm9ybSBhIGZvY3VzZWQNCj4gPiA+IFdHIGZvciB0aGlzIHdvcmsuIA0KPiA+ID4gDQo+ID4gPiBS aWNoYXJkIEJhcm5lcyBwcm9wb3NlZCB0aGlzIGNoYXJ0ZXIgZm9yIHRoZSBXRy4gUGxlYXNlIHRh a2UgYSBsb29rIGFuZA0KPiA+ID4gZmVlbCBmcmVlIHRvIGNvbW1lbnQgb24gdGhlIGRvYyBkaXJl Y3RseSBhbmQgcHJvcG9zZSBvdGhlciBjaGFuZ2VzIGFzDQo+ID4gPiB3ZWxsLg0KPiA+ID4gDQo+ ID4gPiBUaGFua3MNCj4gPiA+IEVtYWQNCj4gPiA+IF9fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fDQo+ID4gPiBkaXNwYXRjaCBtYWlsaW5nIGxpc3QNCj4gPiA+ IGRpc3BhdGNoQGlldGYub3JnDQo+ID4gPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xp c3RpbmZvL2Rpc3BhdGNoDQo+ID4gDQo+ID4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX18NCj4gPiBkaXNwYXRjaCBtYWlsaW5nIGxpc3QNCj4gPiBkaXNwYXRj aEBpZXRmLm9yZw0KPiA+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vZGlz cGF0Y2gNCj4gDQo+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fDQo+IGRpc3BhdGNoIG1haWxpbmcgbGlzdA0KPiBkaXNwYXRjaEBpZXRmLm9yZw0KPiBodHRw czovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2Rpc3BhdGNoDQotLSANCkNoZWVycw0K DQpNYWdudXMgV2VzdGVybHVuZCANCg0KDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQpOZXR3b3JrcywgRXJpY3Nz b24gUmVzZWFyY2gNCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCkVyaWNzc29uIEFCICAgICAgICAgICAgICAgICB8 IFBob25lICArNDYgMTAgNzE0ODI4Nw0KVG9yc2hhbW5zZ2F0YW4gMjMgICAgICAgICAgIHwgTW9i aWxlICs0NiA3MyAwOTQ5MDc5DQpTRS0xNjQgODAgU3RvY2tob2xtLCBTd2VkZW4gfCBtYWlsdG86 IG1hZ251cy53ZXN0ZXJsdW5kQGVyaWNzc29uLmNvbQ0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KDQoNCg== From nobody Wed Aug 5 13:15:32 2020 Return-Path: X-Original-To: sframe@ietfa.amsl.com Delivered-To: sframe@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A2B493A0F3B; Wed, 5 Aug 2020 13:15:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.047 X-Spam-Level: X-Spam-Status: No, score=-3.047 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, NICE_REPLY_A=-0.949, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 BGRczUfIL0GE; Wed, 5 Aug 2020 13:15:29 -0700 (PDT) Received: from mail-wm1-x334.google.com (mail-wm1-x334.google.com [IPv6:2a00:1450:4864:20::334]) (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 1C4C63A0F33; Wed, 5 Aug 2020 13:15:29 -0700 (PDT) Received: by mail-wm1-x334.google.com with SMTP id k8so7579401wma.2; Wed, 05 Aug 2020 13:15:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding:content-language; bh=A8ysl9rSXkzRt/J4/FBm1XQAthQLIeQPn67EenAEKbU=; b=sh8D3o3UY5baMCtcnQZnw39hK3urbb6EiwmCjBAtbFZwLBiKcDeig+7eFWfExyJCMr ZKXqv/9TKHPIhFm21U1zTWmbzyca7NhuUckdnRcYKWkWzic7lcQSGjvCab5/T6Aqg3Yv PKRz1C+agtKC65Ym9CTu93rNki92ixqsEdEbHzb5i8YtOhuxb9/YpvjTORVCqUdfnb+R FTaUt0oP1MIZTSNpNQlpEdyrXuectvabtTgpMY1awli5UKj4WIBtJNZcWpfZ5jB6sAH0 hn8NhOPtdn/yQk0R790mC7G0s7fbaHxz5xxENQx4GgWzcAJ1whavuF5kDdkn09fP0uXX gXFw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding :content-language; bh=A8ysl9rSXkzRt/J4/FBm1XQAthQLIeQPn67EenAEKbU=; b=HbwhPMOPGGDDcmtuQSHZNUhVLb8kC1cD5IuF0thB63oWW/0i8rT+4sY9J6wFiS1rQk A1vaTDYaug65AIbv+jetmb4hkvOrpE/T1+vg9yXBLcUtB83jAjFTzEehx7uJ5qbQIqsX 1rD6Jk5CG5f4/B/fxoXhvMODeHU85cLs/+Z/dpLzqtHxpAgaNXF+OtJgINqdEoPG/ODP 8jAYVH1f2Kygvx2xFXMgTd08jI3oWB3R/yVWCpz9/cT9yaPt8dJEXRk2pBOejzQ7ogvP fWAf4sU9Qjam8AuRHVOUIzceW5LBsK6z9QoIrGhW06kdQsYe5YWKtEAfBvxiHU64cmCC kZDw== X-Gm-Message-State: AOAM532hOfTj8kdKZsgaWJf9eioPxfLGfrplhQ545mL+7x3i5Wa8tNax GeVU/X7/kTmERdnPdkqL+afCbWggN4c= X-Google-Smtp-Source: ABdhPJw+BxxCtUCQ2bZVWKI/GRZeptasjKM/Q99KhUZ32dQ9mXgrjEzC3962QDjgjvki9DVXEHzaSw== X-Received: by 2002:a7b:c84f:: with SMTP id c15mr5056738wml.133.1596658527356; Wed, 05 Aug 2020 13:15:27 -0700 (PDT) Received: from [192.168.1.36] (118.red-79-151-172.dynamicip.rima-tde.net. [79.151.172.118]) by smtp.googlemail.com with ESMTPSA id b77sm3209722wmb.3.2020.08.05.13.15.25 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 05 Aug 2020 13:15:26 -0700 (PDT) To: Magnus Westerlund , "ben@nostrum.com" , "rlb@ipv.sx" Cc: "emadomara=40google.com@dmarc.ietf.org" , "dispatch@ietf.org" , "sframe@ietf.org" References: From: Sergio Garcia Murillo Message-ID: <69181ed1-d72a-99de-8b4d-9e10276ced91@gmail.com> Date: Wed, 5 Aug 2020 22:15:24 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.11.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Archived-At: Subject: Re: [Sframe] [dispatch] SFRame Next Steps (was SFrame proposed WG charter) X-BeenThere: sframe@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Aug 2020 20:15:31 -0000 But shouldn't the "delayed media" attack still be transport agnostic? I mean, this can happen on QUIC and WebRTC SFUs. Anyway, I agree that while SFrame is transport agnostic, the chapter should not ignore the interactions with webrtc/quic and we must ensure that we provide a complete working solution regardless of the transport. If we identify that any further working items are required for a particular transport, we should at liaise with the appropriate working group for providing a solution. Best regards Sergio On 05/08/2020 16:34, Magnus Westerlund wrote: > Hi, > > I want to make one high level comments on the proposed charter for SFRAME. > > The charter attempts to be transport agnostic. However, we know there are > certain use cases this solution needs to support. And I think one of the hardest > from a security perspective is the multi-party centralised one with one or more > SFUs. Based on the significant discussion we had in PERC around threat model, I > think this charter do need to have in its description work to explicitly develop > the threat model as well describe which aspects of the threat model that one can > address. For example I think the security threat of media delay which is an > interesting variant of "replay" attack that exist for real-time media > conversation where there are logic that selects what to forward. > > Cheers > > Magnus Westerlund > > > On Fri, 2020-07-31 at 13:15 -0400, Richard Barnes wrote: >> The link Emad posted should allow for comments, so please feel free to comment >> directly on the doc. >> >> Or you can reply with comments here and we'll get them incorporated. >> >> On Thu, Jul 30, 2020 at 5:59 PM Ben Campbell wrote: >>> Hi everyone, >>> >>> We had a good discussion on SFrame in the dispatch meeting, and a lot of >>> interest in progressing it. The chairs would love it if we can get some >>> discussion of the proposed charter (below) now, while it’s still fresh in >>> people’s minds. If we don’t see feedback to the contrary within a couple of >>> weeks (let’s call that 14 Aug), we will hand it over to the ART ADs. >>> >>> Thanks! >>> >>> Ben. >>> >>>> On Jul 27, 2020, at 12:34 PM, Emad Omara < >>>> emadomara=40google.com@dmarc.ietf.org> wrote: >>>> >>>> Hi dispatch, >>>> >>>> Following up on the discussion we had this morning in IETF 108 dispatch >>>> session about SFrame, it seems there is enough interest to form a focused >>>> WG for this work. >>>> >>>> Richard Barnes proposed this charter for the WG. Please take a look and >>>> feel free to comment on the doc directly and propose other changes as >>>> well. >>>> >>>> Thanks >>>> Emad >>>> _______________________________________________ >>>> dispatch mailing list >>>> dispatch@ietf.org >>>> https://www.ietf.org/mailman/listinfo/dispatch >>> _______________________________________________ >>> dispatch mailing list >>> dispatch@ietf.org >>> https://www.ietf.org/mailman/listinfo/dispatch >> _______________________________________________ >> dispatch mailing list >> dispatch@ietf.org >> https://www.ietf.org/mailman/listinfo/dispatch From nobody Thu Aug 6 01:56:27 2020 Return-Path: X-Original-To: sframe@ietfa.amsl.com Delivered-To: sframe@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A4B83A1023; Thu, 6 Aug 2020 01:56:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.102 X-Spam-Level: X-Spam-Status: No, score=-2.102 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, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H2=-0.001, 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=ericsson.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 yWXSfCgTIRjy; Thu, 6 Aug 2020 01:56:21 -0700 (PDT) Received: from EUR03-VE1-obe.outbound.protection.outlook.com (mail-eopbgr50081.outbound.protection.outlook.com [40.107.5.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 6593A3A100E; Thu, 6 Aug 2020 01:56:20 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=FqPjg/0qOOqMFXn9vN4FWvn+4z5BbQvzJZZIE0iMOImyOxuumFfEvWXt4MPcDiB3Go9sYwfBRWcxVSrggt1luITBN68YjfDwe8C/Rgxm8h8CePCNLB1daYCAVG7sWddB03BC84b3BJW/4vvOFYjqQ2DHRxlUgpbCIRmx4xzjrBSFrS6KtbmecC3pBe2Jvzl0arpeMb4kxRlxvfkwVGaiH8HMiZ62lWMHjHmPVE9qSobbvr3qhY/Cee/XN31x4cruFqABk7v1uCOkSNrarJPJ8PHrL0mTodHeJ8kxi64S3kSOFao8f/1cmY7e1Mq8MaqQI86sRcvXw+ZsIIvmUnr0DQ== 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=GDtl7CvHPnlatE0xz7l+7Sa2+7uglgohhOPkiz/GJfI=; b=hTh1LtUF0sr1uLozdeFCIe3LFPOYond4SaX76yD1GsB1u9Mj4MuPWMrt+MtvFLqV/6EHUIdBsJ2KqY0WSX7bdtcgByCiE3ErDdD/80J3AVQLPUOA2MKjE7LNn0USS3yuYjREZNDtp5kk1bw+EaUf+LEZa0j7VYgp1rL0wlRx9Q6zdAupaJGHowcpKTWc4ZvB/+fYUVx4lAVuvB9j0FjJQ8QfFI7UYSFBtyxmadc6vMKGskz0auAusFpeWpTe549uc8Xvim+yjPSv8LRRWqPxWG+YG3ykV1G+5lkNtZ7EpQUr1dgSthbh02C5DtrzQjseUxnz4xXVYHOH4WWygnU6Yw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=ericsson.com; dmarc=pass action=none header.from=ericsson.com; dkim=pass header.d=ericsson.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=GDtl7CvHPnlatE0xz7l+7Sa2+7uglgohhOPkiz/GJfI=; b=MHps0eehZEPk4VeErNZjEao063LsmWgrp8JF8g9jcT/PCr4MbQyGBKli9mtFglp8pjhmgNg3GHt9DmqPnVB4xJU4bXIBlW7ANrt12dtutxgkBwSL0F7tHcNwQ+jWIXfofWiEY7SM8XLwB2qfb1S12CmlzELLOYZG4kqPlqmyY0Y= Received: from HE1PR0702MB3772.eurprd07.prod.outlook.com (2603:10a6:7:8e::14) by HE1PR07MB3098.eurprd07.prod.outlook.com (2603:10a6:7:38::30) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3261.14; Thu, 6 Aug 2020 08:56:17 +0000 Received: from HE1PR0702MB3772.eurprd07.prod.outlook.com ([fe80::d95a:be8:b97b:582d]) by HE1PR0702MB3772.eurprd07.prod.outlook.com ([fe80::d95a:be8:b97b:582d%5]) with mapi id 15.20.3261.016; Thu, 6 Aug 2020 08:56:17 +0000 From: Magnus Westerlund To: "ben@nostrum.com" , "rlb@ipv.sx" , "sergio.garcia.murillo@gmail.com" CC: "dispatch@ietf.org" , "sframe@ietf.org" , "emadomara@google.com" Thread-Topic: [dispatch] SFRame Next Steps (was SFrame proposed WG charter) Thread-Index: AQHWa2UvSRWiVT7MukOqMgZDT9IOv6kqyBeA Date: Thu, 6 Aug 2020 08:56:16 +0000 Message-ID: <771e108a9f25c1bec04d5fcdad58eb55bbb1533d.camel@ericsson.com> References: <69181ed1-d72a-99de-8b4d-9e10276ced91@gmail.com> In-Reply-To: <69181ed1-d72a-99de-8b4d-9e10276ced91@gmail.com> Accept-Language: sv-SE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-mailer: Evolution 3.28.5-0ubuntu0.18.04.2 authentication-results: nostrum.com; dkim=none (message not signed) header.d=none;nostrum.com; dmarc=none action=none header.from=ericsson.com; x-originating-ip: [98.128.243.14] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 66917b51-16bc-4812-d73b-08d839e69495 x-ms-traffictypediagnostic: HE1PR07MB3098: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: tYJ12woz666PCayrUtgEvmMEzfBbhX5ZkqXZKGeLiW8SX2q4IFpiZl+S2CGjW47uACIVqCMRZKAA22JXTon3WEBmqRQXAk3V7QoEconHrC+ucrh3cr4mpKoSDwuv3gdOlTM6DR1TeGxPjAljbvP3+0OkY2AH3sxZQacLivsDahqMxdIFHK35JloxLV7q2+zOefFMtWML/atID/bOPW8faRBRZcm3eU50O8KoR3lpRYrPX/1JGI1Gi1G+W6pk/mxlaKaMRafZNy7lbUuHaKvbCI35Mu7wVT1KhY/ZQvEV8a0YwF3zMLh93T79AWMyzzpkhsA/vt/zL8/2TqdfgJvFBpXbShhxnaZWw61taA32wG24JoS9MwM9J41hXk9biSxY x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:HE1PR0702MB3772.eurprd07.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(346002)(396003)(136003)(376002)(39860400002)(366004)(2906002)(71200400001)(8676002)(6512007)(5660300002)(36756003)(26005)(66446008)(8936002)(66476007)(66556008)(64756008)(186003)(76116006)(66946007)(2616005)(54906003)(6506007)(478600001)(83380400001)(6486002)(44832011)(86362001)(110136005)(316002)(4326008)(99106002); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: NDeoNyXkAvYIAWVhVrmjmAZEluGUZ3vm3J/IxCtdPyKkxKnl8BBNY1QokHTwLef5rpKUy+9BC14JQPqWnh5KTur7xNTNAEGbOL8qyGcUfcBrFCcTa978tuitc/lhFvGAoGTaSGGfQpJXVzm9VCXoCMk4DnaPCOciEIz7mSxvjZ6F3uBI+aoF57W0z+7rwHT/f17c1AmUl4PvxUCUEQ46YZaqTPJKQY7S9+uDGMWTMz5ACOxzjkLYdMc+b2xsLsA70JEvXQ1d7xrAlLd8kyuERWof75ysY/yBOvks7RnisKNIoBTUlxb8lG0GyPxD8QfiYfUp20Xyoaph4YEhFVLVsxgUuRup/Dm5XsuTWHr0/iaExasU9z3kGI0rfgRBOyBarAHMCjwr81Y1+9aB5A592lNRv869cwmoissWJpRPwHoT4u3f+BJdxI5P9cp8oqVNCm66Cyj4cdltIq2VCHzUoSnuo+4Z6r7gaCTjEdPmBJHPqByd01uiDjRWWrj/QzQRjx6iSpt23NmLu6ujuJQeQNQKyIfrJzEy10p5bKoqcPS1d89C7CXLONhLV33NO8pNTScvvdzv0mo5cA1nSfHKy6BP8bX5JXSGdujtGGez5XEizlDcLzyQmnxFTsEFSjy6ffYH9en9Ts6LBdWqP+98jw== x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: HE1PR0702MB3772.eurprd07.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 66917b51-16bc-4812-d73b-08d839e69495 X-MS-Exchange-CrossTenant-originalarrivaltime: 06 Aug 2020 08:56:16.9645 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: R2CrkpUDhINf+RtFCLXoPNDuzvUihloAe/wLtg4AU+r+g5P6BKtiDA+tq2Xb2T3J6EOItwaRZxgpXEUWWCSmtQtMiZgOsYlDkeFIWsM4Am8= X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR07MB3098 Archived-At: Subject: Re: [Sframe] [dispatch] SFRame Next Steps (was SFrame proposed WG charter) X-BeenThere: sframe@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Aug 2020 08:56:22 -0000 SGksDQoNCk9uIFdlZCwgMjAyMC0wOC0wNSBhdCAyMjoxNSArMDIwMCwgU2VyZ2lvIEdhcmNpYSBN dXJpbGxvIHdyb3RlOg0KPiBCdXQgc2hvdWxkbid0IHRoZSAiZGVsYXllZCBtZWRpYSIgYXR0YWNr IHN0aWxsIGJlIHRyYW5zcG9ydCBhZ25vc3RpYz8gSSANCj4gbWVhbiwgdGhpcyBjYW4gaGFwcGVu IG9uIFFVSUMgYW5kIFdlYlJUQyBTRlVzLg0KDQpTb3JyeSBpZiBJIGdhdmUgdGhlIGltcHJlc3Np b24gdGhhdCBpdCBpcyBub3QgdHJhbnNwb3J0IGFnbm9zdGljLiBJdCBpcyB1c2UgY2FzZQ0KZGVw ZW5kZW50LCBhbnkgdXNlIGNhc2UgdGhhdCBpc24ndCBwb2ludCB0byBwb2ludCwgd2hlcmUgdGhl cmUgaXMgbW9yZSB0aGFuIG9uZQ0KZW50aXR5IHRoYXQgY2FuIGludGVudGlvbmFsbHkgcmVtb3Zl IFNGUkFNRSBjcmVhdGluZyBnYXBzIGluIHRoZSBTRlJBTUUNCnNlcXVlbmNlLiBJbiBhIHBvaW50 IHRvIHBvaW50IHNjZW5hcmlvIG9uZSBjYW4gY29ycmVsYXRlIHRyYW5zcG9ydCBsb3NzZXMgd2l0 aA0KU0ZSQU1FIGdhcHMgdG8ga25vdyBnaXZlIGEgcmVhc29uYWJseSBzdHJvbmcgbWl0aWdhdGlv biBhZ2FpbnN0IGFueSB0aGlyZCBwYXJ0eQ0KcmVtb3ZpbmcgU0ZSQU1FcyBvciBkZWxheWluZyB0 aGVtLiBUaGF0IGlzIG11Y2ggaGFyZGVyIGluIGEgY2VudHJhbGl6ZWQNCmNvbmZlcmVuY2Ugd2l0 aCBvbmUgb3IgbW9yZSBTRlUuDQoNCj4gDQo+IEFueXdheSwgSSBhZ3JlZSB0aGF0IHdoaWxlIFNG cmFtZSBpcyB0cmFuc3BvcnQgYWdub3N0aWMsIHRoZSBjaGFwdGVyIA0KPiBzaG91bGQgbm90IGln bm9yZSB0aGUgaW50ZXJhY3Rpb25zIHdpdGggd2VicnRjL3F1aWMgYW5kIHdlIG11c3QgZW5zdXJl IA0KPiB0aGF0IHdlIHByb3ZpZGUgYSBjb21wbGV0ZSB3b3JraW5nIHNvbHV0aW9uIHJlZ2FyZGxl c3Mgb2YgdGhlIHRyYW5zcG9ydC4gDQo+IElmIHdlIGlkZW50aWZ5IHRoYXQgYW55IGZ1cnRoZXIg d29ya2luZyBpdGVtcyBhcmUgcmVxdWlyZWQgZm9yIGEgDQo+IHBhcnRpY3VsYXIgdHJhbnNwb3J0 LCB3ZSBzaG91bGQgYXQgbGlhaXNlIHdpdGggdGhlIGFwcHJvcHJpYXRlIHdvcmtpbmcgDQo+IGdy b3VwIGZvciBwcm92aWRpbmcgYSBzb2x1dGlvbi4NCg0KTXkgbWFpbiBwb2ludCBpcyB0aGF0IFNG UkFNRSBhY3R1YWxseSBuZWVkcyB0byBkaXNjdXNzIHRoZSB0aHJlYXQgbW9kZWwgZm9yIHRoZQ0K dXNlIGNhc2VzIGl0IGludGVuZGVzIHRvIHNvbHZlLiBBbmQgdGhlIG1pdGlnYXRpb24gY2FuIHBv dGVudGlhbGx5IGluY2x1ZGUNCmZ1bmN0aW9uYWxpdHkgb24gdGhlIHRyYW5zcG9ydCBsZXZlbC4g QnV0IHRoZSByaXNrcyB0byBtZWRpYSBzZWN1cml0eSBpbg0KY2VudHJhbGl6ZWQgY29uZmVyZW5j aW5nIG5lZWRzIHRvIGJlIGRpc2N1c3NlZC4gQW5kIGNlbnRyYWxpemVkIGNvbmZlcmVuY2luZw0K d2lsbCBzdGlsbCBoYXZlIHRoZSBzZW1pLXRydXN0ZWQgU0ZVcyBhbmQgYWxsIHRoZSByZXN0IG9m IHRoZSB0aGlyZCBwYXJ0aWVzIGluDQphZGRpdGlvbiB0byB0aGUgZW5kLXBvaW50cy4gDQoNCkFs c28gd2hhdCBwcm9wZXJ0aWVzIG9uZSBoYXZlIGFyb3VuZCBlbmQtcG9pbnRzIGludml0ZWQgaW50 byB0aGUgY29uZmVyZW5jZSBoYXMNCmEgbnVtYmVyIG9mIHF1ZXN0aW9uIGFyb3VuZCBzZWN1cml0 eSBwcm9wZXJ0aWVzIHRoYXQgbmVlZHMgdG8gYmUgZGlzY3Vzc2VkIGFuZA0KZG9jdW1lbnRlZC4g U29tZSBleGFtcGxlcyB0aGF0IEkga25vdyBhcmUgcmVsZXZhbnQ6DQoNCi0gU291cmNlIGF1dGhl bnRpY2F0aW9uOiBTUlRQIHVubGVzcyBvbmUgdXNlIFRFU0xBICh3aGljaCBpc24ndCByZWFsbHkg dXNlZCkNCmRvZXMgb25seSBwcm92aWRlZCB0aGUgcHJvcGVydHk6IFNvbWVvbmUgdGhhdCBoYXMg dGhlIGtleSBzZW50IHRoaXMuIE9uZSBkb24ndA0Ka25vdyB0aGF0IGl0IGNvbWVzIGZyb20gYSBw YXJ0aWN1bGFyIGVuZHBvaW50LiANCg0KLSBDb25maWRlbnRpYWxpdHkgd2hlbiBncm91cCBtZW1i ZXJzaGlwIGNoYW5nZXM6IFNvIHdpbGwgU0ZSQU1FIGtleWluZyBzdXBwb3J0IGENCnVzZSBjYXNl IHdoZXJlIG9ubHkgdGhlIGN1cnJlbnQgc2V0IG9mIG1lbWJlcnMgaW4gYSBjb25mZXJlbmNlIGNh biBkZWNyeXB0IHRoZQ0KbWVkaWEgYW5kIG9uZSByZWtleSB0aGUgbWVkaWEgc2Vzc2lvbiBrZXkg Zm9yIGVhY2ggdGltZSB0aGUgbWVtYmVyc2hpcCBjaGFuZ2VzPw0KUEVSQyBkbyBzdXBwb3J0IHRo aXMsIHdpbGwgU0ZSQU1FPyANCg0KVGhlcmUgYXJlIGxpa2VseSBtb3JlIHF1ZXN0aW9ucyB0aGF0 IG5lZWRzIGRpc2N1c3Npb24uIFRoZSBQRVJDIGRpc2N1c3Npb24gaXMgYQ0KZ29vZCBzdGFydGlu ZyBwb2ludCwgYnV0IEkgdGhpbmsgd2hlbiBnb2luZyB0cmFuc3BvcnQgYWdub3N0aWMgc29tZSBv ZiB0aGUNCmlzc3VlcyBuZWVkcyB0byBiZSBtb3JlIGNsZWFybHkgZGlzY3Vzc2VkIGFzIHRoZSBS VFAgdHJhbnNwb3J0IGNhbiBoYXZlIGFmZmVjdGVkDQpob3cgaXQgd2FzIGRpc2N1c3NlZCwgYW5k IHdoYXQgcmVsaWFuY2Ugb24gZXhpc3RpbmcgbWVjaGFuaXNtLiBXaGljaCBmb3IgU0ZSQU1FDQps aWtlbHkgcmVxdWlyZSBhIGdlbmVyYWwgZGlzY3Vzc2lvbiBhbmQgdGhlbiByZXF1aXJlbWVudHMg b24gdGhlIHRyYW5zcG9ydCBhbmQNCmludm92bGVkIGVuZHBvaW50cyBhbmQgU0ZVIHRvIGFjY29t cGxpc2ggbWl0aWdhdGlvbnMuIEFuZCB0aHVzIGFsc28gd2hhdCB0aGUNCnJpc2tzIGFyZSBvZiBo YXZpbmcgbm8gbWl0aWdhdGlvbiBpbiBwbGFjZS4gDQoNCkkgd291bGQgcmVhbGx5IHByb3Bvc2Ug dGhhdCBTRlJBTUUgaXMgY2hhcnRlcmVkIHdpdGggcHVibGlzaGluZyBhIHNlY3VyaXR5DQpjb25z aWRlcmF0aW9uIGFuZCB0aHJlYXQgbW9kZWwgZG9jdW1lbnQgdGhhdCBpcyBzZXBlcmF0ZSBmcm9t IHRoZSBzb2x1dGlvbiB0bw0KZ2l2ZSB0aGlzIHRvcGljIGZ1bGwgZm9jdXMuIFRoZSBzb2x1dGlv biB3aWxsIG9mIG5lY2Vzc2l0eSBuZWVkIHRvIHJlZmVyZW5jZQ0KdGhhdCBhbmQgZG9jdW1lbnQg d2hhdCBtaWdpdGFndGlvbnMgdGhhdCBleGlzdHMgaW4gdGhlIFNGUkFNRSBsYXllciBhbmQgd2hh dA0KYmVjb21lcyByZXF1aXJlbWVudHMgb24gdGhlIHRyYW5zcG9ydC4gDQoNCkNoZWVycw0KDQpN YWdudXMgV2VzdGVybHVuZCANCg0KDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQpOZXR3b3JrcywgRXJpY3Nzb24g UmVzZWFyY2gNCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCkVyaWNzc29uIEFCICAgICAgICAgICAgICAgICB8IFBo b25lICArNDYgMTAgNzE0ODI4Nw0KVG9yc2hhbW5zZ2F0YW4gMjMgICAgICAgICAgIHwgTW9iaWxl ICs0NiA3MyAwOTQ5MDc5DQpTRS0xNjQgODAgU3RvY2tob2xtLCBTd2VkZW4gfCBtYWlsdG86IG1h Z251cy53ZXN0ZXJsdW5kQGVyaWNzc29uLmNvbQ0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KDQoNCg== From nobody Thu Aug 6 11:02:47 2020 Return-Path: X-Original-To: sframe@ietfa.amsl.com Delivered-To: sframe@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F0253A0D6D for ; Thu, 6 Aug 2020 11:02:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.599 X-Spam-Level: X-Spam-Status: No, score=-17.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.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 hXSRkONY9qfy for ; Thu, 6 Aug 2020 11:02:40 -0700 (PDT) Received: from mail-ed1-x52f.google.com (mail-ed1-x52f.google.com [IPv6:2a00:1450:4864:20::52f]) (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 9BD753A0D6B for ; Thu, 6 Aug 2020 11:02:39 -0700 (PDT) Received: by mail-ed1-x52f.google.com with SMTP id l23so22082952edv.11 for ; Thu, 06 Aug 2020 11:02:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=KwWIcyCIpEZLiY5RPZx1QFB0bGnEaVlxTKu1/3XZeuk=; b=tdhjNHILmReN6y3K9Uwjw5DWhVLBTd0BCb/4KF2tgIT82VqDvQQqHYMhg0Vbo/uoll 8T7Qsl3HQQzvDLXp4AqKcNfyCe/RwIMP8eWFkXvXrxmYgx3dPJ2nIMNri+tAE2LET/Qb DQcHlfHXf7wBUqj+8yQAoXCFyDqnVIIYjVq9kyrSQxzjMcKXY8aIAzIqBql7okdW1OCQ +a7oF3qlJJjwoZwsDksU6H10jgFIk0htxu4VMM6csuYoAusxz85MXGu+OkajDi1P183w FfP2pivv4TsmHU9ffArW3kHxMOeFvyxI5FCJss/vLBcRuMuGhV09n17pAj3NFThpjicE VxxA== 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=KwWIcyCIpEZLiY5RPZx1QFB0bGnEaVlxTKu1/3XZeuk=; b=uTayyas3cYa5zJEYPV1fSFzDEOIiVYd1YRobgR+He+I8GFwTrpoLs06lN1mTULy4aU ZGUciUxBn3eMkMxOnoRZSH3Xmc/9p+Ga6OBVmSWJudbXkF8JILSRBtBSwKQ7mptNDjhs wlyfKvNOpz+NHXiSw2m13FHw7fIVDCkgrZSiuYarajHMpLXonQbsr9BKL8EO/IZaWXMH oKpkABjNuMk6WNJM4IEM/oby1E+MNgJwdRa8qx2JBsUUUNHVRNaxD1LxKfUfjjgzdumH Z7gWSLoB1G9IiyF46ymH6xHOkM9igD86dRQhqk+DKS0xUYsEyB2us8aj9sUytua1vXxL AzPw== X-Gm-Message-State: AOAM532E75ENpPwwcFHZb5DbcP1hU4ADb0VGtBKPtm3HL3ZHsBgwIiLY mjlv09gBWaKycvb0doYT5oRGzypIVxMIy3EcXB3C X-Google-Smtp-Source: ABdhPJxdtdp0dHp6mqoPZqKCH7Y9fCguRSV4dObIJ14Qs371M5dngjz4pYBRZg6qj29wHjKvS3brK6dN8rj4l63KxoY= X-Received: by 2002:aa7:cd46:: with SMTP id v6mr4951572edw.21.1596736957845; Thu, 06 Aug 2020 11:02:37 -0700 (PDT) MIME-Version: 1.0 References: <69181ed1-d72a-99de-8b4d-9e10276ced91@gmail.com> <771e108a9f25c1bec04d5fcdad58eb55bbb1533d.camel@ericsson.com> In-Reply-To: <771e108a9f25c1bec04d5fcdad58eb55bbb1533d.camel@ericsson.com> From: Emad Omara Date: Thu, 6 Aug 2020 11:02:26 -0700 Message-ID: To: Magnus Westerlund Cc: "ben@nostrum.com" , "rlb@ipv.sx" , "sergio.garcia.murillo@gmail.com" , "dispatch@ietf.org" , "sframe@ietf.org" Content-Type: multipart/alternative; boundary="0000000000002c5c9f05ac394b45" Archived-At: Subject: Re: [Sframe] [dispatch] SFRame Next Steps (was SFrame proposed WG charter) X-BeenThere: sframe@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Aug 2020 18:02:43 -0000 --0000000000002c5c9f05ac394b45 Content-Type: text/plain; charset="UTF-8" Thanks Magnus. I like the idea to explicitly call out the threat model, I think it will be good foundations that control all future design decisions, however I'm not sure if the charter is the right place to call this out. I'd recommend having a separate document that describes the system architecture, goals and threat model. What do you think? Emad On Thu, Aug 6, 2020 at 1:56 AM Magnus Westerlund < magnus.westerlund@ericsson.com> wrote: > Hi, > > On Wed, 2020-08-05 at 22:15 +0200, Sergio Garcia Murillo wrote: > > But shouldn't the "delayed media" attack still be transport agnostic? I > > mean, this can happen on QUIC and WebRTC SFUs. > > Sorry if I gave the impression that it is not transport agnostic. It is > use case > dependent, any use case that isn't point to point, where there is more > than one > entity that can intentionally remove SFRAME creating gaps in the SFRAME > sequence. In a point to point scenario one can correlate transport losses > with > SFRAME gaps to know give a reasonably strong mitigation against any third > party > removing SFRAMEs or delaying them. That is much harder in a centralized > conference with one or more SFU. > > > > > Anyway, I agree that while SFrame is transport agnostic, the chapter > > should not ignore the interactions with webrtc/quic and we must ensure > > that we provide a complete working solution regardless of the transport. > > If we identify that any further working items are required for a > > particular transport, we should at liaise with the appropriate working > > group for providing a solution. > > My main point is that SFRAME actually needs to discuss the threat model > for the > use cases it intendes to solve. And the mitigation can potentially include > functionality on the transport level. But the risks to media security in > centralized conferencing needs to be discussed. And centralized > conferencing > will still have the semi-trusted SFUs and all the rest of the third > parties in > addition to the end-points. > > Also what properties one have around end-points invited into the > conference has > a number of question around security properties that needs to be discussed > and > documented. Some examples that I know are relevant: > > - Source authentication: SRTP unless one use TESLA (which isn't really > used) > does only provided the property: Someone that has the key sent this. One > don't > know that it comes from a particular endpoint. > > - Confidentiality when group membership changes: So will SFRAME keying > support a > use case where only the current set of members in a conference can decrypt > the > media and one rekey the media session key for each time the membership > changes? > PERC do support this, will SFRAME? > > There are likely more questions that needs discussion. The PERC discussion > is a > good starting point, but I think when going transport agnostic some of the > issues needs to be more clearly discussed as the RTP transport can have > affected > how it was discussed, and what reliance on existing mechanism. Which for > SFRAME > likely require a general discussion and then requirements on the transport > and > invovled endpoints and SFU to accomplish mitigations. And thus also what > the > risks are of having no mitigation in place. > > I would really propose that SFRAME is chartered with publishing a security > consideration and threat model document that is seperate from the solution > to > give this topic full focus. The solution will of necessity need to > reference > that and document what migitagtions that exists in the SFRAME layer and > what > becomes requirements on the transport. > > Cheers > > Magnus Westerlund > > > ---------------------------------------------------------------------- > Networks, Ericsson Research > ---------------------------------------------------------------------- > Ericsson AB | Phone +46 10 7148287 > <+46%2010%20714%2082%2087> > Torshamnsgatan 23 | Mobile +46 73 0949079 > <+46%2073%20094%2090%2079> > SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com > ---------------------------------------------------------------------- > > > --0000000000002c5c9f05ac394b45 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thanks Magnus. I like the idea to explicitly call out the = threat model, I think it will be good foundations that control all future d= esign decisions, however I'm not sure if the charter is the right place= to call this out. I'd recommend having a separate document that descri= bes=C2=A0the system architecture, goals and threat model. What do you think= ?

Emad

On Thu, Aug 6, 2020 at 1:56 AM Magnus Wester= lund <magnus.westerlun= d@ericsson.com> wrote:
Hi,

On Wed, 2020-08-05 at 22:15 +0200, Sergio Garcia Murillo wrote:
> But shouldn't the "delayed media" attack still be transp= ort agnostic? I
> mean, this can happen on QUIC and WebRTC SFUs.

Sorry if I gave the impression that it is not transport agnostic. It is use= case
dependent, any use case that isn't point to point, where there is more = than one
entity that can intentionally remove SFRAME creating gaps in the SFRAME
sequence. In a point to point scenario one can correlate transport losses w= ith
SFRAME gaps to know give a reasonably strong mitigation against any third p= arty
removing SFRAMEs or delaying them. That is much harder in a centralized
conference with one or more SFU.

>
> Anyway, I agree that while SFrame is transport agnostic, the chapter <= br> > should not ignore the interactions with webrtc/quic and we must ensure=
> that we provide a complete working solution regardless of the transpor= t.
> If we identify that any further working items are required for a
> particular transport, we should at liaise with the appropriate working=
> group for providing a solution.

My main point is that SFRAME actually needs to discuss the threat model for= the
use cases it intendes to solve. And the mitigation can potentially include<= br> functionality on the transport level. But the risks to media security in centralized conferencing needs to be discussed. And centralized conferencin= g
will still have the semi-trusted SFUs and all the rest of the third parties= in
addition to the end-points.

Also what properties one have around end-points invited into the conference= has
a number of question around security properties that needs to be discussed = and
documented. Some examples that I know are relevant:

- Source authentication: SRTP unless one use TESLA (which isn't really = used)
does only provided the property: Someone that has the key sent this. One do= n't
know that it comes from a particular endpoint.

- Confidentiality when group membership changes: So will SFRAME keying supp= ort a
use case where only the current set of members in a conference can decrypt = the
media and one rekey the media session key for each time the membership chan= ges?
PERC do support this, will SFRAME?

There are likely more questions that needs discussion. The PERC discussion = is a
good starting point, but I think when going transport agnostic some of the<= br> issues needs to be more clearly discussed as the RTP transport can have aff= ected
how it was discussed, and what reliance on existing mechanism. Which for SF= RAME
likely require a general discussion and then requirements on the transport = and
invovled endpoints and SFU to accomplish mitigations. And thus also what th= e
risks are of having no mitigation in place.

I would really propose that SFRAME is chartered with publishing a security<= br> consideration and threat model document that is seperate from the solution = to
give this topic full focus. The solution will of necessity need to referenc= e
that and document what migitagtions that exists in the SFRAME layer and wha= t
becomes requirements on the transport.

Cheers

Magnus Westerlund


----------------------------------------------------------------------
Networks, Ericsson Research
----------------------------------------------------------------------
Ericsson AB=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| = Phone=C2=A0 +46 10 7148287
Torshamnsgatan 23=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| Mobile = +46 73 0949079
SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com
----------------------------------------------------------------------


--0000000000002c5c9f05ac394b45-- From nobody Fri Aug 7 20:51:21 2020 Return-Path: X-Original-To: sframe@ietfa.amsl.com Delivered-To: sframe@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C0913A0C2F for ; Fri, 7 Aug 2020 20:51:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=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=cosmosoftware-io.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 p_9wFCoaOjE6 for ; Fri, 7 Aug 2020 20:51:16 -0700 (PDT) Received: from mail-ot1-x32b.google.com (mail-ot1-x32b.google.com [IPv6:2607:f8b0:4864:20::32b]) (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 D28473A0C32 for ; Fri, 7 Aug 2020 20:51:16 -0700 (PDT) Received: by mail-ot1-x32b.google.com with SMTP id a65so3165050otc.8 for ; Fri, 07 Aug 2020 20:51:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cosmosoftware-io.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=imSr3jez8a6v0Nn3rBShIoMEgthfm8/4ZGv9IAvcv1g=; b=Jwnl7fmEJGrW/o8WBsKXr++b2O3TLfcSjhXVyJKWlMDebADHRRuGNrQFhiyXGvz8qB x5EftS06YHy0A2Lx81A5PQfdI/zTc8UcS/u3pA8y96tAqDB86HS6VyzbpGis0tWhg4aP vGSrDn4/zmxd4cjYrMOz6DCmGnYjR1ncHOIyhDhdM4zcgNd3pSSfuWmWz+oI48cv/A9F G2T/UBcvtOFHhKpLD/ONvdqf5Idi2efMDkd6rLgn8HnAZQg8MsCOVTBz1nrHSMiFasGV cE4JNX3uESMU/fBXOuIz8gtwSrwgWMqWGx3dflzEUXV/5TUfESZ/nVr2USJaAbAO4GRO fcDg== 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=imSr3jez8a6v0Nn3rBShIoMEgthfm8/4ZGv9IAvcv1g=; b=oWRC81rMDo4bgqNPGucOK85r6jvVxndMhEquaw+aI7PeveTh2sMDVVLC52sCm6Dl3o xqUyJZdBtATXbvSq/MXOO+isXGkWOb6G28jFbOXoX9TZlwcwh2ynJaCIt4k4/r2x/qPS ZO0LmOzaELwZ5dXsd9nl7Rt62EzVKle1+iUlYYfnZ7tFr9rknuYby3rER8T5t8oHQxXS eXAdP2ow8Sz4XBNUxDjcgaYrO2oTaAfcRupi8d3f9G+L83avWaSe64igxWz4YAe6rBun WOrCHT5vyHsPVHSJvgsxOvrgh1xditK1yD5aey6/m6smqTbXCELFYHRJL9ZiZHiPDUpT 2rlQ== X-Gm-Message-State: AOAM533daWO41slnEDLCMkxWRnvqlQYTyBmUdt5qmwLiKBpTWTCf8nHu d/XMVIlObjLK+GMAPxipdqQ1oyD43KfnKIs+a8MdIg== X-Google-Smtp-Source: ABdhPJwuhUadYuOal9JFmTPyTMZ+lCXl0yWGONerFVzCqHt1kixUz+Tv/0rNDZdQbqiRU6b5+XgyZ7Xz1goe/UF1PhE= X-Received: by 2002:a9d:5616:: with SMTP id e22mr15491969oti.255.1596858676027; Fri, 07 Aug 2020 20:51:16 -0700 (PDT) MIME-Version: 1.0 References: <69181ed1-d72a-99de-8b4d-9e10276ced91@gmail.com> <771e108a9f25c1bec04d5fcdad58eb55bbb1533d.camel@ericsson.com> In-Reply-To: From: Alexandre GOUAILLARD Date: Sat, 8 Aug 2020 11:51:05 +0800 Message-ID: To: Emad Omara Cc: Magnus Westerlund , "rlb@ipv.sx" , "ben@nostrum.com" , "dispatch@ietf.org" , "sergio.garcia.murillo@gmail.com" , "sframe@ietf.org" Content-Type: multipart/alternative; boundary="000000000000243a0005ac55a264" Archived-At: Subject: Re: [Sframe] [dispatch] SFRame Next Steps (was SFrame proposed WG charter) X-BeenThere: sframe@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Aug 2020 03:51:19 -0000 --000000000000243a0005ac55a264 Content-Type: text/plain; charset="UTF-8" guys, sorry for jumping in so late, quarantine here is very strict. We had long discussions about this specific point ahead of the draft submission. We had reached the following consensus: - there are multiple usage of media over the internet, e.g. conferencing and streaming/broadcast - they have very different threat/trust models, with different solutions implemented today (transport layer E / E2EE / DRM / Encrypted Media Extentions / ...) - they all can benefit from SFrame PERC was, by design, limited to RTP and to Conferencing. Many other use case coul benefit from Enhanced Privacy. We concluded that it would be better to keep SFrame (the media encryption part, equivalent to PERC double conceptually), and to have separated documents that describe the threat models and the corresponding key exchange, signaling and system level decision for each use case. Emad had taken an action item for example to make two additional documents to describe the Video Conferencing use case, and how SFrame could be used in conjunction with MLS to address that specific use case. Someone else could take the different use case of the Browsers (which have a specific trust model) and make a document showing how SFrame con work with Insertable Frame API (and likely some more) to address that use case. CoSMo is interested in doing the same thing for Real-Time streaming/Broadcasting. I think it is a more reasonable approach as, even spending a lot of time brainstorming with everyone around the tabel including bernard, we couldn't think about one solution to fit all the different "media over internet"'s threat model. In my mind, each case should first have an informal document to define scope and threat model, and subsequent document to define the corresponding specifications. - Secure Conferencing Threat model (emad and co.) - Secure Conferencing Signalling using MLS (emad and co.) - Secure Conferencing using MLS In the browser (contributed by w3c people) Magnus, what do you think? Regards, Dr. ALex. On Fri, Aug 7, 2020 at 2:02 AM Emad Omara wrote: > Thanks Magnus. I like the idea to explicitly call out the threat model, I > think it will be good foundations that control all future design decisions, > however I'm not sure if the charter is the right place to call this out. > I'd recommend having a separate document that describes the system > architecture, goals and threat model. What do you think? > > Emad > > On Thu, Aug 6, 2020 at 1:56 AM Magnus Westerlund < > magnus.westerlund@ericsson.com> wrote: > >> Hi, >> >> On Wed, 2020-08-05 at 22:15 +0200, Sergio Garcia Murillo wrote: >> > But shouldn't the "delayed media" attack still be transport agnostic? I >> > mean, this can happen on QUIC and WebRTC SFUs. >> >> Sorry if I gave the impression that it is not transport agnostic. It is >> use case >> dependent, any use case that isn't point to point, where there is more >> than one >> entity that can intentionally remove SFRAME creating gaps in the SFRAME >> sequence. In a point to point scenario one can correlate transport losses >> with >> SFRAME gaps to know give a reasonably strong mitigation against any third >> party >> removing SFRAMEs or delaying them. That is much harder in a centralized >> conference with one or more SFU. >> >> > >> > Anyway, I agree that while SFrame is transport agnostic, the chapter >> > should not ignore the interactions with webrtc/quic and we must ensure >> > that we provide a complete working solution regardless of the >> transport. >> > If we identify that any further working items are required for a >> > particular transport, we should at liaise with the appropriate working >> > group for providing a solution. >> >> My main point is that SFRAME actually needs to discuss the threat model >> for the >> use cases it intendes to solve. And the mitigation can potentially include >> functionality on the transport level. But the risks to media security in >> centralized conferencing needs to be discussed. And centralized >> conferencing >> will still have the semi-trusted SFUs and all the rest of the third >> parties in >> addition to the end-points. >> >> Also what properties one have around end-points invited into the >> conference has >> a number of question around security properties that needs to be >> discussed and >> documented. Some examples that I know are relevant: >> >> - Source authentication: SRTP unless one use TESLA (which isn't really >> used) >> does only provided the property: Someone that has the key sent this. One >> don't >> know that it comes from a particular endpoint. >> >> - Confidentiality when group membership changes: So will SFRAME keying >> support a >> use case where only the current set of members in a conference can >> decrypt the >> media and one rekey the media session key for each time the membership >> changes? >> PERC do support this, will SFRAME? >> >> There are likely more questions that needs discussion. The PERC >> discussion is a >> good starting point, but I think when going transport agnostic some of the >> issues needs to be more clearly discussed as the RTP transport can have >> affected >> how it was discussed, and what reliance on existing mechanism. Which for >> SFRAME >> likely require a general discussion and then requirements on the >> transport and >> invovled endpoints and SFU to accomplish mitigations. And thus also what >> the >> risks are of having no mitigation in place. >> >> I would really propose that SFRAME is chartered with publishing a security >> consideration and threat model document that is seperate from the >> solution to >> give this topic full focus. The solution will of necessity need to >> reference >> that and document what migitagtions that exists in the SFRAME layer and >> what >> becomes requirements on the transport. >> >> Cheers >> >> Magnus Westerlund >> >> >> ---------------------------------------------------------------------- >> Networks, Ericsson Research >> ---------------------------------------------------------------------- >> Ericsson AB | Phone +46 10 7148287 >> <+46%2010%20714%2082%2087> >> Torshamnsgatan 23 | Mobile +46 73 0949079 >> <+46%2073%20094%2090%2079> >> SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com >> ---------------------------------------------------------------------- >> >> >> -- > Sframe mailing list > Sframe@ietf.org > https://www.ietf.org/mailman/listinfo/sframe > --000000000000243a0005ac55a264 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
guys,

sorry for jumping in so late, qua= rantine here is very strict.

We had long discussio= ns about this specific point ahead of the draft submission.
We ha= d reached the following consensus:
- there are multiple usage of = media over the internet, e.g. conferencing and streaming/broadcast
- they have very different threat/trust models, with different solutions = implemented today (transport layer E / E2EE / DRM / Encrypted Media Extenti= ons / ...)
- they all can benefit from SFrame

PERC was, by design, limited to RTP and to Conferencing. Many other u= se case coul benefit=C2=A0from Enhanced=C2=A0Privacy.

<= div>We concluded that it would be better to keep SFrame (the media encrypti= on part, equivalent to PERC double conceptually), and to have separated doc= uments that=C2=A0describe the threat models and the corresponding key excha= nge,=C2=A0signaling=C2=A0and system level decision for each use case. Emad = had taken an action item for example to make two additional=C2=A0documents = to describe the Video Conferencing use case,=C2=A0and how SFrame could be u= sed in conjunction with MLS to address that specific use case. Someone else= could take the different use case of the Browsers=C2=A0(which have a speci= fic trust model) and make a document showing how SFrame con work with Inser= table Frame API (and likely some more) to address that use case. CoSMo is i= nterested in doing the same thing for Real-Time streaming/Broadcasting.

I think it is a more reasonable=C2=A0approach as, eve= n spending a lot of time brainstorming with everyone around the tabel inclu= ding bernard, we couldn't think about one solution to fit all the diffe= rent "media over internet"'s threat model. In my mind, each c= ase should first have an informal document to define scope and threat model= , and subsequent document to define the corresponding specifications.=C2=A0=
- Secure Conferencing Threat model (emad and co.)
- Se= cure Conferencing Signalling using MLS (emad and co.)
- Secure Co= nferencing using MLS In the browser (contributed by w3c people)
<= br>
Magnus, what do you think?

Regards,= =C2=A0

Dr. ALex.



On Fri, Aug 7, 2020 at 2:02 AM Emad Omara <emadomara=3D40google.com@dmarc.ietf.org> wrote:<= br>
Thanks Magnus. I like the idea t= o explicitly call out the threat model, I think it will be good foundations= that control all future design decisions, however I'm not sure if the = charter is the right place to call this out. I'd recommend having a sep= arate document that describes=C2=A0the system architecture, goals and threa= t model. What do you think?

Emad

On Thu, Aug 6, 202= 0 at 1:56 AM Magnus Westerlund <magnus.westerlund@ericsson.com> wrote:
Hi,

On Wed, 2020-08-05 at 22:15 +0200, Sergio Garcia Murillo wrote:
> But shouldn't the "delayed media" attack still be transp= ort agnostic? I
> mean, this can happen on QUIC and WebRTC SFUs.

Sorry if I gave the impression that it is not transport agnostic. It is use= case
dependent, any use case that isn't point to point, where there is more = than one
entity that can intentionally remove SFRAME creating gaps in the SFRAME
sequence. In a point to point scenario one can correlate transport losses w= ith
SFRAME gaps to know give a reasonably strong mitigation against any third p= arty
removing SFRAMEs or delaying them. That is much harder in a centralized
conference with one or more SFU.

>
> Anyway, I agree that while SFrame is transport agnostic, the chapter <= br> > should not ignore the interactions with webrtc/quic and we must ensure=
> that we provide a complete working solution regardless of the transpor= t.
> If we identify that any further working items are required for a
> particular transport, we should at liaise with the appropriate working=
> group for providing a solution.

My main point is that SFRAME actually needs to discuss the threat model for= the
use cases it intendes to solve. And the mitigation can potentially include<= br> functionality on the transport level. But the risks to media security in centralized conferencing needs to be discussed. And centralized conferencin= g
will still have the semi-trusted SFUs and all the rest of the third parties= in
addition to the end-points.

Also what properties one have around end-points invited into the conference= has
a number of question around security properties that needs to be discussed = and
documented. Some examples that I know are relevant:

- Source authentication: SRTP unless one use TESLA (which isn't really = used)
does only provided the property: Someone that has the key sent this. One do= n't
know that it comes from a particular endpoint.

- Confidentiality when group membership changes: So will SFRAME keying supp= ort a
use case where only the current set of members in a conference can decrypt = the
media and one rekey the media session key for each time the membership chan= ges?
PERC do support this, will SFRAME?

There are likely more questions that needs discussion. The PERC discussion = is a
good starting point, but I think when going transport agnostic some of the<= br> issues needs to be more clearly discussed as the RTP transport can have aff= ected
how it was discussed, and what reliance on existing mechanism. Which for SF= RAME
likely require a general discussion and then requirements on the transport = and
invovled endpoints and SFU to accomplish mitigations. And thus also what th= e
risks are of having no mitigation in place.

I would really propose that SFRAME is chartered with publishing a security<= br> consideration and threat model document that is seperate from the solution = to
give this topic full focus. The solution will of necessity need to referenc= e
that and document what migitagtions that exists in the SFRAME layer and wha= t
becomes requirements on the transport.

Cheers

Magnus Westerlund


----------------------------------------------------------------------
Networks, Ericsson Research
----------------------------------------------------------------------
Ericsson AB=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| = Phone=C2=A0 +46 10 7148287
Torshamnsgatan 23=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| Mobile = +46 73 0949079
SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com
----------------------------------------------------------------------


--
Sframe mailing list
Sframe@ietf.org https://www.ietf.org/mailman/listinfo/sframe
--000000000000243a0005ac55a264-- From nobody Wed Aug 12 08:11:56 2020 Return-Path: X-Original-To: sframe@ietfa.amsl.com Delivered-To: sframe@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A14A53A13D2 for ; Wed, 12 Aug 2020 08:11:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ipv-sx.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 W5ib1PqQ7Tha for ; Wed, 12 Aug 2020 08:11:49 -0700 (PDT) Received: from mail-qv1-xf30.google.com (mail-qv1-xf30.google.com [IPv6:2607:f8b0:4864:20::f30]) (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 5FE2E3A13D0 for ; Wed, 12 Aug 2020 08:11:49 -0700 (PDT) Received: by mail-qv1-xf30.google.com with SMTP id cs12so1175724qvb.2 for ; Wed, 12 Aug 2020 08:11:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ipv-sx.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=HB6JIsnOjLHWtBADwjN3QcY1OaXtIYAdm8jtbNL5TBM=; b=e3tBpUbnB0nHO42z0K3TXlOm2UU0fTFVYlyfuVGzpQd81ENhOtoFdw5WxphVgN/e9n cy1GgnulCtbNV68RvQSpuhiWdByFMLw2K8hBp7vVJJMb+F0T58DTqatWVQWOn8+omo4s YlP/KlZT2O7EoCo1rYMPrzRLvUdVeIjcJevM3VAy2QlCZtvrySdtZfuO1LaxAB7RKiHq 5AmfTWrqjz1i8iYxsJK9/gdLsMW7PqoeNNNZUXHEeTvL62yCL9axYB+cUyUYmmbw/i7K 6RrJnaEMIR6k02j6ByvRPuPowBhBo7/UIPz2iNskvHZLnDE7NqmXT486gTqDGytl4md4 rz0g== 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=HB6JIsnOjLHWtBADwjN3QcY1OaXtIYAdm8jtbNL5TBM=; b=LXzF06hpkamTMrWYIaLqeFN5Hn4C8rVm4yd0cnurTXHFalJ0Cf+Uoy9wqSPbCPBeYm C26ONI4gd4nxykpPBp94ynrsvSW1X/8ewDeWvT3KdqGogq5nUV6AmsVrH6k9Iz+FLQ7K 46+aXe+L8SawarbigTaGY4sHDokeC3QlKQGc3Dlbdqi8GYoeQwnvKMfx5ZLIpgz7nXWo wJrG7aiQxT5HCMfidPGtMT/l5F7v+dys8R5dzQwNkIFXrE2vZNbuvMPvSm8/ENe87Dp1 BcxQ8zpDXwi+sbj7fSIzd3yXIMxDilm5NcmX8aGIisVAkVNhwdTOPuxdrNK4GAS6yB6j 1xaA== X-Gm-Message-State: AOAM5329zECBbfrIkAzs5NPNB10hF7J4tF2liWfPUbxzCGB6N+JNYqXZ deM4Ub2Mzugs1LW6sYbppAx0PD3F5lu0cNLbFgo6/Q== X-Google-Smtp-Source: ABdhPJxfff1rdUVBskUGn92bY190knYNWAoaeMM4PIiR585WjcZnCYp3lecBMuHu3tGRnKnMl7WzaYoMyscmRivzlW0= X-Received: by 2002:a0c:fc07:: with SMTP id z7mr4805qvo.65.1597245108190; Wed, 12 Aug 2020 08:11:48 -0700 (PDT) MIME-Version: 1.0 References: <69181ed1-d72a-99de-8b4d-9e10276ced91@gmail.com> <771e108a9f25c1bec04d5fcdad58eb55bbb1533d.camel@ericsson.com> In-Reply-To: From: Richard Barnes Date: Wed, 12 Aug 2020 11:11:33 -0400 Message-ID: To: Alexandre GOUAILLARD Cc: Emad Omara , Magnus Westerlund , "ben@nostrum.com" , "dispatch@ietf.org" , "sergio.garcia.murillo@gmail.com" , "sframe@ietf.org" Content-Type: multipart/alternative; boundary="0000000000004b16af05acaf9b2d" Archived-At: Subject: Re: [Sframe] [dispatch] SFRame Next Steps (was SFrame proposed WG charter) X-BeenThere: sframe@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Aug 2020 15:11:53 -0000 --0000000000004b16af05acaf9b2d Content-Type: text/plain; charset="UTF-8" Hey all, I agree that all of this stuff is valuable to capture somewhere. In the interest of keeping the charter fairly succinct, I've added the following: """ The SFrame specification will detail the specific security properties that the encapsulation provides, and discuss their implications under common usage scenarios / threat models. """ With that, I think that all the comments we've gotten so far have been addressed. --Richard On Fri, Aug 7, 2020 at 11:51 PM Alexandre GOUAILLARD < Alex.GOUAILLARD@cosmosoftware.io> wrote: > guys, > > sorry for jumping in so late, quarantine here is very strict. > > We had long discussions about this specific point ahead of the draft > submission. > We had reached the following consensus: > - there are multiple usage of media over the internet, e.g. conferencing > and streaming/broadcast > - they have very different threat/trust models, with different solutions > implemented today (transport layer E / E2EE / DRM / Encrypted Media > Extentions / ...) > - they all can benefit from SFrame > > PERC was, by design, limited to RTP and to Conferencing. Many other use > case coul benefit from Enhanced Privacy. > > We concluded that it would be better to keep SFrame (the media encryption > part, equivalent to PERC double conceptually), and to have separated > documents that describe the threat models and the corresponding key > exchange, signaling and system level decision for each use case. Emad had > taken an action item for example to make two additional documents to > describe the Video Conferencing use case, and how SFrame could be used in > conjunction with MLS to address that specific use case. Someone else could > take the different use case of the Browsers (which have a specific trust > model) and make a document showing how SFrame con work with Insertable > Frame API (and likely some more) to address that use case. CoSMo is > interested in doing the same thing for Real-Time streaming/Broadcasting. > > I think it is a more reasonable approach as, even spending a lot of time > brainstorming with everyone around the tabel including bernard, we couldn't > think about one solution to fit all the different "media over internet"'s > threat model. In my mind, each case should first have an informal document > to define scope and threat model, and subsequent document to define the > corresponding specifications. > - Secure Conferencing Threat model (emad and co.) > - Secure Conferencing Signalling using MLS (emad and co.) > - Secure Conferencing using MLS In the browser (contributed by w3c people) > > Magnus, what do you think? > > Regards, > > Dr. ALex. > > > > On Fri, Aug 7, 2020 at 2:02 AM Emad Omara 40google.com@dmarc.ietf.org> wrote: > >> Thanks Magnus. I like the idea to explicitly call out the threat model, I >> think it will be good foundations that control all future design decisions, >> however I'm not sure if the charter is the right place to call this out. >> I'd recommend having a separate document that describes the system >> architecture, goals and threat model. What do you think? >> >> Emad >> >> On Thu, Aug 6, 2020 at 1:56 AM Magnus Westerlund < >> magnus.westerlund@ericsson.com> wrote: >> >>> Hi, >>> >>> On Wed, 2020-08-05 at 22:15 +0200, Sergio Garcia Murillo wrote: >>> > But shouldn't the "delayed media" attack still be transport agnostic? >>> I >>> > mean, this can happen on QUIC and WebRTC SFUs. >>> >>> Sorry if I gave the impression that it is not transport agnostic. It is >>> use case >>> dependent, any use case that isn't point to point, where there is more >>> than one >>> entity that can intentionally remove SFRAME creating gaps in the SFRAME >>> sequence. In a point to point scenario one can correlate transport >>> losses with >>> SFRAME gaps to know give a reasonably strong mitigation against any >>> third party >>> removing SFRAMEs or delaying them. That is much harder in a centralized >>> conference with one or more SFU. >>> >>> > >>> > Anyway, I agree that while SFrame is transport agnostic, the chapter >>> > should not ignore the interactions with webrtc/quic and we must ensure >>> > that we provide a complete working solution regardless of the >>> transport. >>> > If we identify that any further working items are required for a >>> > particular transport, we should at liaise with the appropriate working >>> > group for providing a solution. >>> >>> My main point is that SFRAME actually needs to discuss the threat model >>> for the >>> use cases it intendes to solve. And the mitigation can potentially >>> include >>> functionality on the transport level. But the risks to media security in >>> centralized conferencing needs to be discussed. And centralized >>> conferencing >>> will still have the semi-trusted SFUs and all the rest of the third >>> parties in >>> addition to the end-points. >>> >>> Also what properties one have around end-points invited into the >>> conference has >>> a number of question around security properties that needs to be >>> discussed and >>> documented. Some examples that I know are relevant: >>> >>> - Source authentication: SRTP unless one use TESLA (which isn't really >>> used) >>> does only provided the property: Someone that has the key sent this. One >>> don't >>> know that it comes from a particular endpoint. >>> >>> - Confidentiality when group membership changes: So will SFRAME keying >>> support a >>> use case where only the current set of members in a conference can >>> decrypt the >>> media and one rekey the media session key for each time the membership >>> changes? >>> PERC do support this, will SFRAME? >>> >>> There are likely more questions that needs discussion. The PERC >>> discussion is a >>> good starting point, but I think when going transport agnostic some of >>> the >>> issues needs to be more clearly discussed as the RTP transport can have >>> affected >>> how it was discussed, and what reliance on existing mechanism. Which for >>> SFRAME >>> likely require a general discussion and then requirements on the >>> transport and >>> invovled endpoints and SFU to accomplish mitigations. And thus also what >>> the >>> risks are of having no mitigation in place. >>> >>> I would really propose that SFRAME is chartered with publishing a >>> security >>> consideration and threat model document that is seperate from the >>> solution to >>> give this topic full focus. The solution will of necessity need to >>> reference >>> that and document what migitagtions that exists in the SFRAME layer and >>> what >>> becomes requirements on the transport. >>> >>> Cheers >>> >>> Magnus Westerlund >>> >>> >>> ---------------------------------------------------------------------- >>> Networks, Ericsson Research >>> ---------------------------------------------------------------------- >>> Ericsson AB | Phone +46 10 7148287 >>> <+46%2010%20714%2082%2087> >>> Torshamnsgatan 23 | Mobile +46 73 0949079 >>> <+46%2073%20094%2090%2079> >>> SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com >>> ---------------------------------------------------------------------- >>> >>> >>> -- >> Sframe mailing list >> Sframe@ietf.org >> https://www.ietf.org/mailman/listinfo/sframe >> > --0000000000004b16af05acaf9b2d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hey all,

I agree that all of= this stuff is valuable to capture somewhere.=C2=A0 In the interest of keep= ing the charter fairly succinct, I've added the following:

"= ;""
The SFrame specification will detail the specific s= ecurity properties that the encapsulation provides, and discuss their impli= cations under common usage scenarios / threat models.
""= ;"

With that, I think that all the comments w= e've gotten so far have been addressed.

--Rich= ard


On Fri, Aug 7, 2020 at 11:51 PM Alexandre GOU= AILLARD <Alex.GOUAIL= LARD@cosmosoftware.io> wrote:
guys,

sorry for ju= mping in so late, quarantine here is very strict.

= We had long discussions about this specific point ahead of the draft submis= sion.
We had reached the following consensus:
- there a= re multiple usage of media over the internet, e.g. conferencing and streami= ng/broadcast
- they have very different threat/trust models, with= different solutions implemented today (transport layer E / E2EE / DRM / En= crypted Media Extentions / ...)
- they all can benefit from SFram= e

PERC was, by design, limited to RTP and to Confe= rencing. Many other use case coul benefit=C2=A0from Enhanced=C2=A0Privacy.<= /div>

We concluded that it would be better to keep SFram= e (the media encryption part, equivalent to PERC double conceptually), and = to have separated documents that=C2=A0describe the threat models and the co= rresponding key exchange,=C2=A0signaling=C2=A0and system level decision for= each use case. Emad had taken an action item for example to make two addit= ional=C2=A0documents to describe the Video Conferencing use case,=C2=A0and = how SFrame could be used in conjunction with MLS to address that specific u= se case. Someone else could take the different use case of the Browsers=C2= =A0(which have a specific trust model) and make a document showing how SFra= me con work with Insertable Frame API (and likely some more) to address tha= t use case. CoSMo is interested in doing the same thing for Real-Time strea= ming/Broadcasting.

I think it is a more reasonable= =C2=A0approach as, even spending a lot of time brainstorming with everyone = around the tabel including bernard, we couldn't think about one solutio= n to fit all the different "media over internet"'s threat mod= el. In my mind, each case should first have an informal document to define = scope and threat model, and subsequent document to define the corresponding= specifications.=C2=A0
- Secure Conferencing Threat model (emad a= nd co.)
- Secure Conferencing Signalling using MLS (emad and co.)=
- Secure Conferencing using MLS In the browser (contributed by w= 3c people)

Magnus, what do you think?
Regards,=C2=A0

Dr. ALex.


On Fri, Aug 7, 2020 at 2:02 AM Emad Omara <emadom= ara=3D40go= ogle.com@dmarc.ietf.org> wrote:
Thanks Magnus. I like the idea to e= xplicitly call out the threat model, I think it will be good foundations th= at control all future design decisions, however I'm not sure if the cha= rter is the right place to call this out. I'd recommend having a separa= te document that describes=C2=A0the system architecture, goals and threat m= odel. What do you think?

Emad

On Thu, Aug 6, 2020 = at 1:56 AM Magnus Westerlund <magnus.westerlund@ericsson.com> wrote:
=
Hi,

On Wed, 2020-08-05 at 22:15 +0200, Sergio Garcia Murillo wrote:
> But shouldn't the "delayed media" attack still be transp= ort agnostic? I
> mean, this can happen on QUIC and WebRTC SFUs.

Sorry if I gave the impression that it is not transport agnostic. It is use= case
dependent, any use case that isn't point to point, where there is more = than one
entity that can intentionally remove SFRAME creating gaps in the SFRAME
sequence. In a point to point scenario one can correlate transport losses w= ith
SFRAME gaps to know give a reasonably strong mitigation against any third p= arty
removing SFRAMEs or delaying them. That is much harder in a centralized
conference with one or more SFU.

>
> Anyway, I agree that while SFrame is transport agnostic, the chapter <= br> > should not ignore the interactions with webrtc/quic and we must ensure=
> that we provide a complete working solution regardless of the transpor= t.
> If we identify that any further working items are required for a
> particular transport, we should at liaise with the appropriate working=
> group for providing a solution.

My main point is that SFRAME actually needs to discuss the threat model for= the
use cases it intendes to solve. And the mitigation can potentially include<= br> functionality on the transport level. But the risks to media security in centralized conferencing needs to be discussed. And centralized conferencin= g
will still have the semi-trusted SFUs and all the rest of the third parties= in
addition to the end-points.

Also what properties one have around end-points invited into the conference= has
a number of question around security properties that needs to be discussed = and
documented. Some examples that I know are relevant:

- Source authentication: SRTP unless one use TESLA (which isn't really = used)
does only provided the property: Someone that has the key sent this. One do= n't
know that it comes from a particular endpoint.

- Confidentiality when group membership changes: So will SFRAME keying supp= ort a
use case where only the current set of members in a conference can decrypt = the
media and one rekey the media session key for each time the membership chan= ges?
PERC do support this, will SFRAME?

There are likely more questions that needs discussion. The PERC discussion = is a
good starting point, but I think when going transport agnostic some of the<= br> issues needs to be more clearly discussed as the RTP transport can have aff= ected
how it was discussed, and what reliance on existing mechanism. Which for SF= RAME
likely require a general discussion and then requirements on the transport = and
invovled endpoints and SFU to accomplish mitigations. And thus also what th= e
risks are of having no mitigation in place.

I would really propose that SFRAME is chartered with publishing a security<= br> consideration and threat model document that is seperate from the solution = to
give this topic full focus. The solution will of necessity need to referenc= e
that and document what migitagtions that exists in the SFRAME layer and wha= t
becomes requirements on the transport.

Cheers

Magnus Westerlund


----------------------------------------------------------------------
Networks, Ericsson Research
----------------------------------------------------------------------
Ericsson AB=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| = Phone=C2=A0 +46 10 7148287
Torshamnsgatan 23=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| Mobile = +46 73 0949079
SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com
----------------------------------------------------------------------


--
Sframe mailing list
Sframe@ietf.org https://www.ietf.org/mailman/listinfo/sframe
--0000000000004b16af05acaf9b2d-- From nobody Mon Aug 31 07:06:22 2020 Return-Path: X-Original-To: sframe@ietfa.amsl.com Delivered-To: sframe@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0A6833A13C0; Mon, 31 Aug 2020 07:06:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.101 X-Spam-Level: X-Spam-Status: No, score=-2.101 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, DKIM_VALID_EF=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.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 2O2to1y27iTm; Mon, 31 Aug 2020 07:06:15 -0700 (PDT) Received: from EUR04-HE1-obe.outbound.protection.outlook.com (mail-he1eur04on0603.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe0d::603]) (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 E3A193A13C5; Mon, 31 Aug 2020 07:06:14 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=bUjcdGLKMhS1ybm07BJwPTlIm+dbNPW8oSAFHY4yWGEbcHB+XvDk/9rPoTJIfpUn2vQE7DbNuO/2kb/oZuF9qArkZghKu+ssp72urRrq1A68JhlUiMbjrzIjBix0OMkpIUDgcSBTJ6Zd2E7fXrnwnT8P4QX09v8kT3R2NyHR0mMAcHvwGDbXQifV/I7AMYcxtV2YIA5/44NpXhbg5gBJzjZzErcmkHYwyMwhVVu9Ca/N8NdBDV6vW3oI5DJrNwoaoxsi60maIJFUsvXz96WFpcuAzE2WyyDAjvyIHSYjFvKhPxdTDrNjuRDfbohU0hLTkSZ5BIPgDYWdhhNs6QKvYg== 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=Mxh++eJCYuw+Q1S0kTPlhMYBGRrDHNIOjsO9kq8OOzI=; b=h6ejl7NyQibMPajJADizRTndxV4E3EDBxovuVbtFJ+SMwS4CiVmVAMIll7hEyQ7YYk+MtkVCu5cXmYj1kPmEKIs7wBmNKQGy2neLlZU8kuItqm9ANomEaqiWmQ1tDVvOZUotCOVxfWkfvsjL5zWUEWWbsVdYO5rNITTX/Ya7j/+NmF9j9hyWTV+YXGguGtDHJGqMpc7Srl35VH3hrKCtne7d/Biqc63gHjVJNhArtgGi3H/QdQ49R56ji7rYCf5xojLjEyWR3a2OC+MRwomnQAsEJZDGyMd3BeFbg2rXSaPAi2LzE/5vHTsnjeB5sUfrWUpuC5ul3byCAG6fQdzzZw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=ericsson.com; dmarc=pass action=none header.from=ericsson.com; dkim=pass header.d=ericsson.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=Mxh++eJCYuw+Q1S0kTPlhMYBGRrDHNIOjsO9kq8OOzI=; b=Utcou7MovFovwKsNmaYs2MjKETm4YDJGlgd3Cgna0bh9wkX+39tFries0STpRf2lIUI1YmgM1P9wpGF5etfOVBVTMUa9CC0nFA16rHcLg8HeJe9cLTbKeWEHTih8L0LmL1bBGZGTeRgslnnaLX7HXpp8t9BkQ61bGACuOH/whig= Received: from HE1PR0702MB3772.eurprd07.prod.outlook.com (2603:10a6:7:8e::14) by HE1PR0701MB2684.eurprd07.prod.outlook.com (2603:10a6:3:8f::12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3348.5; Mon, 31 Aug 2020 14:06:07 +0000 Received: from HE1PR0702MB3772.eurprd07.prod.outlook.com ([fe80::b56f:9a8e:3399:aaa3]) by HE1PR0702MB3772.eurprd07.prod.outlook.com ([fe80::b56f:9a8e:3399:aaa3%7]) with mapi id 15.20.3348.013; Mon, 31 Aug 2020 14:06:07 +0000 From: Magnus Westerlund To: "Alex.GOUAILLARD@cosmosoftware.io" , "rlb@ipv.sx" CC: "ben@nostrum.com" , "emadomara=40google.com@dmarc.ietf.org" , "dispatch@ietf.org" , "sframe@ietf.org" , "sergio.garcia.murillo@gmail.com" Thread-Topic: [Sframe] [dispatch] SFRame Next Steps (was SFrame proposed WG charter) Thread-Index: AQHWa2UvSRWiVT7MukOqMgZDT9IOv6kqyBeAgACYmgCAAjbMgIAHB3KAgB3KAwA= Date: Mon, 31 Aug 2020 14:06:07 +0000 Message-ID: References: <69181ed1-d72a-99de-8b4d-9e10276ced91@gmail.com> <771e108a9f25c1bec04d5fcdad58eb55bbb1533d.camel@ericsson.com> In-Reply-To: Accept-Language: sv-SE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-mailer: Evolution 3.28.5-0ubuntu0.18.04.2 authentication-results: cosmosoftware.io; dkim=none (message not signed) header.d=none;cosmosoftware.io; dmarc=none action=none header.from=ericsson.com; x-originating-ip: [192.176.1.82] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: c7ff1093-c580-449c-643b-08d84db701bd x-ms-traffictypediagnostic: HE1PR0701MB2684: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: y8Vgxonwb4D9UxfavlNPca0diwLzYeZeYFBWVeeePVafFCGriTFJWKrG96R1WAB0eOARWDb/UUwLF/6lcAv4ZmrWr1pfqO7eSAgXDf/nxDKjiSXrIJaVYTsy1db9wuIQSFMULvn1uuKKTCqwsgQWEwQiqY9OIh5nTTt/gqwn6B0Kw9PVTmhOZpupGhXFm20COPUxJGzsi5lymJEERcEWRxPfQ6AO28A2d1j4z0YH1rwIBjiLE3RYtT5MVeIdS14YRPa8pMWq6c2//tMPoBtMoYKwDMGHAW2XvGcuHAF44Nry7g6m3qPPlKlJ//RsVv0eRbipYZ0G4CXFC6QkZ7Vn/a3lgMS3HFBotYPQMMCpKo3RkBJv7hkjemeaf/9sMuqn x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:HE1PR0702MB3772.eurprd07.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(136003)(396003)(39860400002)(376002)(346002)(366004)(8676002)(2906002)(4326008)(6506007)(5660300002)(71200400001)(66574015)(8936002)(2616005)(26005)(66946007)(44832011)(54906003)(91956017)(76116006)(86362001)(83380400001)(110136005)(316002)(6486002)(186003)(53546011)(36756003)(66476007)(66446008)(66556008)(64756008)(478600001)(6512007)(99106002); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: JJrrmyh8jI3FV/IWeLj06cWbCCJd8Ebo8KTKULhemlT7WjLFP2vwtDDJVIKyLjP6ZqBy4f2BTBx6ZLTmVGo0mEfSdd2zrZ4Qz48HIyoIOReERpxfsqynco3V/gV7gQVKKOPwVc7gptSZGw9T2oJzL1NWpzkGqA3o5bndYxuNDbfTnIatzVFYTyfp/PYzBoKPAnZYSAEUJd4JX4p+VfJT6XZZ7CmIyohSXg0Ub9wodE9s2BIVhzUWRvvbDnUe2I4nirEDEPVl4YBy1I62eD7NvT4vLMlp4Ma0KI7jMd8h56Od84SzFSxMjkyNew4CmrxmTGYHWouex19pizcjUnqy8tbPm3rikcLAWQYJde8W/rdsQ9yT9/M5a/bbWJIZo4OvmnFNwMPtXI/tmYO2H2pXyI5AWaARCU7nTDVp2qB30Lh3Xxtq7TpTyKqFHJjW0CkEj8c/1saJcksBlNEn/aMIoRAhX6zHemVWDroRK8DGLiVYanroCIjXstiICUcN82XASlje8OG24qglr/XGnnYdDGbj9rswibYlvO+ppQEaDulQ9pi5o1sPSWVgYDbe2x1raID1VERhJL0kyiuWHkHqiSRYXuSPXJYa7POZaisiyXyeaQayOEiWz4Dxw/RmeFMWT+oFEf9ohtmGVmTIEh/1WQ== x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-ID: <5BAF39630585E24CB8FE8BCFF2975B67@eurprd07.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: HE1PR0702MB3772.eurprd07.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: c7ff1093-c580-449c-643b-08d84db701bd X-MS-Exchange-CrossTenant-originalarrivaltime: 31 Aug 2020 14:06:07.4919 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: Ka1oWKRDcEG482p1fYTHfI1dDw+mDKL+PxbzF6Gr5wkNgA+TyD3XfZ9pDn9S5okfyafpPxopBhtg8Io8/mMCG8bItL4FYxCYEKKM7pvVYXQ= X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR0701MB2684 Archived-At: Subject: Re: [Sframe] [dispatch] SFRame Next Steps (was SFrame proposed WG charter) X-BeenThere: sframe@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Aug 2020 14:06:17 -0000 SGksDQoNClRoYW5rcyBmb3Igd29ya2luZyBvbiBhZGRyZXNzaW5nIG15IGNvbW1lbnRzIHdoZW4g b24gdmFjYXRpb24uDQoNCkkgdGhpbmsgeW91IG1vc3RseSBhcnJhdmllZCBhdCBhIGdvb2QgcGxh Y2UuIEhvd2V2ZXIsIEkgd291bGQgbGlrZSB0byBtYWtlIG9uZQ0KcmVtYXJrIGFib3V0IHRoZSBh ZGRlZCBsYW5ndWFnZS4NCg0KV2hlbiBpdCBjb21lcyB0byB0aHJlYXQgbW9kZWxzIGl0IGNhbid0 IGJlIHRoZSBpbnRlcnNlY3Rpb24gb2YgdGhyZWF0cyBhY3Jvc3MNCnRob3NlIHRoYXQgb2NjdXIg aW4gdGhlIGludGVuZGVkIHVzYWdlcywgaXQgbmVlZHMgdG8gYmUgdGhlIHVuaW9uIG9mIHRocmVh dHMuDQpUaGUgZm9ybXVsYXRpb24gYWRkZWQgaW1wbGllcyBpbnRlcnNlY3Rpb24gdG8gbWUuIA0K DQpDaGVlcnMNCg0KTWFnbnVzDQoNCk9uIFdlZCwgMjAyMC0wOC0xMiBhdCAxMToxMSAtMDQwMCwg UmljaGFyZCBCYXJuZXMgd3JvdGU6DQo+IEhleSBhbGwsDQo+IA0KPiBJIGFncmVlIHRoYXQgYWxs IG9mIHRoaXMgc3R1ZmYgaXMgdmFsdWFibGUgdG8gY2FwdHVyZSBzb21ld2hlcmUuICBJbiB0aGUN Cj4gaW50ZXJlc3Qgb2Yga2VlcGluZyB0aGUgY2hhcnRlciBmYWlybHkgc3VjY2luY3QsIEkndmUg YWRkZWQgdGhlIGZvbGxvd2luZzoNCj4gDQo+ICIiIg0KPiBUaGUgU0ZyYW1lIHNwZWNpZmljYXRp b24gd2lsbCBkZXRhaWwgdGhlIHNwZWNpZmljIHNlY3VyaXR5IHByb3BlcnRpZXMgdGhhdCB0aGUN Cj4gZW5jYXBzdWxhdGlvbiBwcm92aWRlcywgYW5kIGRpc2N1c3MgdGhlaXIgaW1wbGljYXRpb25z IHVuZGVyIGNvbW1vbiB1c2FnZQ0KPiBzY2VuYXJpb3MgLyB0aHJlYXQgbW9kZWxzLg0KPiAiIiIN Cj4gDQo+IFdpdGggdGhhdCwgSSB0aGluayB0aGF0IGFsbCB0aGUgY29tbWVudHMgd2UndmUgZ290 dGVuIHNvIGZhciBoYXZlIGJlZW4NCj4gYWRkcmVzc2VkLg0KPiANCj4gLS1SaWNoYXJkDQo+IA0K PiANCj4gT24gRnJpLCBBdWcgNywgMjAyMCBhdCAxMTo1MSBQTSBBbGV4YW5kcmUgR09VQUlMTEFS RCA8DQo+IEFsZXguR09VQUlMTEFSREBjb3Ntb3NvZnR3YXJlLmlvPiB3cm90ZToNCj4gPiBndXlz LA0KPiA+IA0KPiA+IHNvcnJ5IGZvciBqdW1waW5nIGluIHNvIGxhdGUsIHF1YXJhbnRpbmUgaGVy ZSBpcyB2ZXJ5IHN0cmljdC4NCj4gPiANCj4gPiBXZSBoYWQgbG9uZyBkaXNjdXNzaW9ucyBhYm91 dCB0aGlzIHNwZWNpZmljIHBvaW50IGFoZWFkIG9mIHRoZSBkcmFmdA0KPiA+IHN1Ym1pc3Npb24u DQo+ID4gV2UgaGFkIHJlYWNoZWQgdGhlIGZvbGxvd2luZyBjb25zZW5zdXM6DQo+ID4gLSB0aGVy ZSBhcmUgbXVsdGlwbGUgdXNhZ2Ugb2YgbWVkaWEgb3ZlciB0aGUgaW50ZXJuZXQsIGUuZy4gY29u ZmVyZW5jaW5nIGFuZA0KPiA+IHN0cmVhbWluZy9icm9hZGNhc3QNCj4gPiAtIHRoZXkgaGF2ZSB2 ZXJ5IGRpZmZlcmVudCB0aHJlYXQvdHJ1c3QgbW9kZWxzLCB3aXRoIGRpZmZlcmVudCBzb2x1dGlv bnMNCj4gPiBpbXBsZW1lbnRlZCB0b2RheSAodHJhbnNwb3J0IGxheWVyIEUgLyBFMkVFIC8gRFJN IC8gRW5jcnlwdGVkIE1lZGlhDQo+ID4gRXh0ZW50aW9ucyAvIC4uLikNCj4gPiAtIHRoZXkgYWxs IGNhbiBiZW5lZml0IGZyb20gU0ZyYW1lDQo+ID4gDQo+ID4gUEVSQyB3YXMsIGJ5IGRlc2lnbiwg bGltaXRlZCB0byBSVFAgYW5kIHRvIENvbmZlcmVuY2luZy4gTWFueSBvdGhlciB1c2UgY2FzZQ0K PiA+IGNvdWwgYmVuZWZpdCBmcm9tIEVuaGFuY2VkIFByaXZhY3kuDQo+ID4gDQo+ID4gV2UgY29u Y2x1ZGVkIHRoYXQgaXQgd291bGQgYmUgYmV0dGVyIHRvIGtlZXAgU0ZyYW1lICh0aGUgbWVkaWEg ZW5jcnlwdGlvbg0KPiA+IHBhcnQsIGVxdWl2YWxlbnQgdG8gUEVSQyBkb3VibGUgY29uY2VwdHVh bGx5KSwgYW5kIHRvIGhhdmUgc2VwYXJhdGVkDQo+ID4gZG9jdW1lbnRzIHRoYXQgZGVzY3JpYmUg dGhlIHRocmVhdCBtb2RlbHMgYW5kIHRoZSBjb3JyZXNwb25kaW5nIGtleQ0KPiA+IGV4Y2hhbmdl LCBzaWduYWxpbmcgYW5kIHN5c3RlbSBsZXZlbCBkZWNpc2lvbiBmb3IgZWFjaCB1c2UgY2FzZS4g RW1hZCBoYWQNCj4gPiB0YWtlbiBhbiBhY3Rpb24gaXRlbSBmb3IgZXhhbXBsZSB0byBtYWtlIHR3 byBhZGRpdGlvbmFsIGRvY3VtZW50cyB0bw0KPiA+IGRlc2NyaWJlIHRoZSBWaWRlbyBDb25mZXJl bmNpbmcgdXNlIGNhc2UsIGFuZCBob3cgU0ZyYW1lIGNvdWxkIGJlIHVzZWQgaW4NCj4gPiBjb25q dW5jdGlvbiB3aXRoIE1MUyB0byBhZGRyZXNzIHRoYXQgc3BlY2lmaWMgdXNlIGNhc2UuIFNvbWVv bmUgZWxzZSBjb3VsZA0KPiA+IHRha2UgdGhlIGRpZmZlcmVudCB1c2UgY2FzZSBvZiB0aGUgQnJv d3NlcnMgKHdoaWNoIGhhdmUgYSBzcGVjaWZpYyB0cnVzdA0KPiA+IG1vZGVsKSBhbmQgbWFrZSBh IGRvY3VtZW50IHNob3dpbmcgaG93IFNGcmFtZSBjb24gd29yayB3aXRoIEluc2VydGFibGUgRnJh bWUNCj4gPiBBUEkgKGFuZCBsaWtlbHkgc29tZSBtb3JlKSB0byBhZGRyZXNzIHRoYXQgdXNlIGNh c2UuIENvU01vIGlzIGludGVyZXN0ZWQgaW4NCj4gPiBkb2luZyB0aGUgc2FtZSB0aGluZyBmb3Ig UmVhbC1UaW1lIHN0cmVhbWluZy9Ccm9hZGNhc3RpbmcuDQo+ID4gDQo+ID4gSSB0aGluayBpdCBp cyBhIG1vcmUgcmVhc29uYWJsZSBhcHByb2FjaCBhcywgZXZlbiBzcGVuZGluZyBhIGxvdCBvZiB0 aW1lDQo+ID4gYnJhaW5zdG9ybWluZyB3aXRoIGV2ZXJ5b25lIGFyb3VuZCB0aGUgdGFiZWwgaW5j bHVkaW5nIGJlcm5hcmQsIHdlIGNvdWxkbid0DQo+ID4gdGhpbmsgYWJvdXQgb25lIHNvbHV0aW9u IHRvIGZpdCBhbGwgdGhlIGRpZmZlcmVudCAibWVkaWEgb3ZlciBpbnRlcm5ldCIncw0KPiA+IHRo cmVhdCBtb2RlbC4gSW4gbXkgbWluZCwgZWFjaCBjYXNlIHNob3VsZCBmaXJzdCBoYXZlIGFuIGlu Zm9ybWFsIGRvY3VtZW50DQo+ID4gdG8gZGVmaW5lIHNjb3BlIGFuZCB0aHJlYXQgbW9kZWwsIGFu ZCBzdWJzZXF1ZW50IGRvY3VtZW50IHRvIGRlZmluZSB0aGUNCj4gPiBjb3JyZXNwb25kaW5nIHNw ZWNpZmljYXRpb25zLiANCj4gPiAtIFNlY3VyZSBDb25mZXJlbmNpbmcgVGhyZWF0IG1vZGVsIChl bWFkIGFuZCBjby4pDQo+ID4gLSBTZWN1cmUgQ29uZmVyZW5jaW5nIFNpZ25hbGxpbmcgdXNpbmcg TUxTIChlbWFkIGFuZCBjby4pDQo+ID4gLSBTZWN1cmUgQ29uZmVyZW5jaW5nIHVzaW5nIE1MUyBJ biB0aGUgYnJvd3NlciAoY29udHJpYnV0ZWQgYnkgdzNjIHBlb3BsZSkNCj4gPiANCj4gPiBNYWdu dXMsIHdoYXQgZG8geW91IHRoaW5rPw0KPiA+IA0KPiA+IFJlZ2FyZHMsIA0KPiA+IA0KPiA+IERy LiBBTGV4Lg0KPiA+IA0KPiA+IA0KPiA+IA0KPiA+IE9uIEZyaSwgQXVnIDcsIDIwMjAgYXQgMjow MiBBTSBFbWFkIE9tYXJhIDwNCj4gPiBlbWFkb21hcmE9NDBnb29nbGUuY29tQGRtYXJjLmlldGYu b3JnPiB3cm90ZToNCj4gPiA+IFRoYW5rcyBNYWdudXMuIEkgbGlrZSB0aGUgaWRlYSB0byBleHBs aWNpdGx5IGNhbGwgb3V0IHRoZSB0aHJlYXQgbW9kZWwsIEkNCj4gPiA+IHRoaW5rIGl0IHdpbGwg YmUgZ29vZCBmb3VuZGF0aW9ucyB0aGF0IGNvbnRyb2wgYWxsIGZ1dHVyZSBkZXNpZ24NCj4gPiA+ IGRlY2lzaW9ucywgaG93ZXZlciBJJ20gbm90IHN1cmUgaWYgdGhlIGNoYXJ0ZXIgaXMgdGhlIHJp Z2h0IHBsYWNlIHRvIGNhbGwNCj4gPiA+IHRoaXMgb3V0LiBJJ2QgcmVjb21tZW5kIGhhdmluZyBh IHNlcGFyYXRlIGRvY3VtZW50IHRoYXQgZGVzY3JpYmVzIHRoZQ0KPiA+ID4gc3lzdGVtIGFyY2hp dGVjdHVyZSwgZ29hbHMgYW5kIHRocmVhdCBtb2RlbC4gV2hhdCBkbyB5b3UgdGhpbms/DQo+ID4g PiANCj4gPiA+IEVtYWQNCj4gPiA+IA0KPiA+ID4gT24gVGh1LCBBdWcgNiwgMjAyMCBhdCAxOjU2 IEFNIE1hZ251cyBXZXN0ZXJsdW5kIDwNCj4gPiA+IG1hZ251cy53ZXN0ZXJsdW5kQGVyaWNzc29u LmNvbT4gd3JvdGU6DQo+ID4gPiA+IEhpLA0KPiA+ID4gPiANCj4gPiA+ID4gT24gV2VkLCAyMDIw LTA4LTA1IGF0IDIyOjE1ICswMjAwLCBTZXJnaW8gR2FyY2lhIE11cmlsbG8gd3JvdGU6DQo+ID4g PiA+ID4gQnV0IHNob3VsZG4ndCB0aGUgImRlbGF5ZWQgbWVkaWEiIGF0dGFjayBzdGlsbCBiZSB0 cmFuc3BvcnQgYWdub3N0aWM/DQo+ID4gPiA+IEkgDQo+ID4gPiA+ID4gbWVhbiwgdGhpcyBjYW4g aGFwcGVuIG9uIFFVSUMgYW5kIFdlYlJUQyBTRlVzLg0KPiA+ID4gPiANCj4gPiA+ID4gU29ycnkg aWYgSSBnYXZlIHRoZSBpbXByZXNzaW9uIHRoYXQgaXQgaXMgbm90IHRyYW5zcG9ydCBhZ25vc3Rp Yy4gSXQgaXMNCj4gPiA+ID4gdXNlIGNhc2UNCj4gPiA+ID4gZGVwZW5kZW50LCBhbnkgdXNlIGNh c2UgdGhhdCBpc24ndCBwb2ludCB0byBwb2ludCwgd2hlcmUgdGhlcmUgaXMgbW9yZQ0KPiA+ID4g PiB0aGFuIG9uZQ0KPiA+ID4gPiBlbnRpdHkgdGhhdCBjYW4gaW50ZW50aW9uYWxseSByZW1vdmUg U0ZSQU1FIGNyZWF0aW5nIGdhcHMgaW4gdGhlIFNGUkFNRQ0KPiA+ID4gPiBzZXF1ZW5jZS4gSW4g YSBwb2ludCB0byBwb2ludCBzY2VuYXJpbyBvbmUgY2FuIGNvcnJlbGF0ZSB0cmFuc3BvcnQNCj4g PiA+ID4gbG9zc2VzIHdpdGgNCj4gPiA+ID4gU0ZSQU1FIGdhcHMgdG8ga25vdyBnaXZlIGEgcmVh c29uYWJseSBzdHJvbmcgbWl0aWdhdGlvbiBhZ2FpbnN0IGFueQ0KPiA+ID4gPiB0aGlyZCBwYXJ0 eQ0KPiA+ID4gPiByZW1vdmluZyBTRlJBTUVzIG9yIGRlbGF5aW5nIHRoZW0uIFRoYXQgaXMgbXVj aCBoYXJkZXIgaW4gYSBjZW50cmFsaXplZA0KPiA+ID4gPiBjb25mZXJlbmNlIHdpdGggb25lIG9y IG1vcmUgU0ZVLg0KPiA+ID4gPiANCj4gPiA+ID4gPiANCj4gPiA+ID4gPiBBbnl3YXksIEkgYWdy ZWUgdGhhdCB3aGlsZSBTRnJhbWUgaXMgdHJhbnNwb3J0IGFnbm9zdGljLCB0aGUgY2hhcHRlciAN Cj4gPiA+ID4gPiBzaG91bGQgbm90IGlnbm9yZSB0aGUgaW50ZXJhY3Rpb25zIHdpdGggd2VicnRj L3F1aWMgYW5kIHdlIG11c3QNCj4gPiA+ID4gZW5zdXJlIA0KPiA+ID4gPiA+IHRoYXQgd2UgcHJv dmlkZSBhIGNvbXBsZXRlIHdvcmtpbmcgc29sdXRpb24gcmVnYXJkbGVzcyBvZiB0aGUNCj4gPiA+ ID4gdHJhbnNwb3J0LiANCj4gPiA+ID4gPiBJZiB3ZSBpZGVudGlmeSB0aGF0IGFueSBmdXJ0aGVy IHdvcmtpbmcgaXRlbXMgYXJlIHJlcXVpcmVkIGZvciBhIA0KPiA+ID4gPiA+IHBhcnRpY3VsYXIg dHJhbnNwb3J0LCB3ZSBzaG91bGQgYXQgbGlhaXNlIHdpdGggdGhlIGFwcHJvcHJpYXRlDQo+ID4g PiA+IHdvcmtpbmcgDQo+ID4gPiA+ID4gZ3JvdXAgZm9yIHByb3ZpZGluZyBhIHNvbHV0aW9uLg0K PiA+ID4gPiANCj4gPiA+ID4gTXkgbWFpbiBwb2ludCBpcyB0aGF0IFNGUkFNRSBhY3R1YWxseSBu ZWVkcyB0byBkaXNjdXNzIHRoZSB0aHJlYXQgbW9kZWwNCj4gPiA+ID4gZm9yIHRoZQ0KPiA+ID4g PiB1c2UgY2FzZXMgaXQgaW50ZW5kZXMgdG8gc29sdmUuIEFuZCB0aGUgbWl0aWdhdGlvbiBjYW4g cG90ZW50aWFsbHkNCj4gPiA+ID4gaW5jbHVkZQ0KPiA+ID4gPiBmdW5jdGlvbmFsaXR5IG9uIHRo ZSB0cmFuc3BvcnQgbGV2ZWwuIEJ1dCB0aGUgcmlza3MgdG8gbWVkaWEgc2VjdXJpdHkgaW4NCj4g PiA+ID4gY2VudHJhbGl6ZWQgY29uZmVyZW5jaW5nIG5lZWRzIHRvIGJlIGRpc2N1c3NlZC4gQW5k IGNlbnRyYWxpemVkDQo+ID4gPiA+IGNvbmZlcmVuY2luZw0KPiA+ID4gPiB3aWxsIHN0aWxsIGhh dmUgdGhlIHNlbWktdHJ1c3RlZCBTRlVzIGFuZCBhbGwgdGhlIHJlc3Qgb2YgdGhlIHRoaXJkDQo+ ID4gPiA+IHBhcnRpZXMgaW4NCj4gPiA+ID4gYWRkaXRpb24gdG8gdGhlIGVuZC1wb2ludHMuIA0K PiA+ID4gPiANCj4gPiA+ID4gQWxzbyB3aGF0IHByb3BlcnRpZXMgb25lIGhhdmUgYXJvdW5kIGVu ZC1wb2ludHMgaW52aXRlZCBpbnRvIHRoZQ0KPiA+ID4gPiBjb25mZXJlbmNlIGhhcw0KPiA+ID4g PiBhIG51bWJlciBvZiBxdWVzdGlvbiBhcm91bmQgc2VjdXJpdHkgcHJvcGVydGllcyB0aGF0IG5l ZWRzIHRvIGJlDQo+ID4gPiA+IGRpc2N1c3NlZCBhbmQNCj4gPiA+ID4gZG9jdW1lbnRlZC4gU29t ZSBleGFtcGxlcyB0aGF0IEkga25vdyBhcmUgcmVsZXZhbnQ6DQo+ID4gPiA+IA0KPiA+ID4gPiAt IFNvdXJjZSBhdXRoZW50aWNhdGlvbjogU1JUUCB1bmxlc3Mgb25lIHVzZSBURVNMQSAod2hpY2gg aXNuJ3QgcmVhbGx5DQo+ID4gPiA+IHVzZWQpDQo+ID4gPiA+IGRvZXMgb25seSBwcm92aWRlZCB0 aGUgcHJvcGVydHk6IFNvbWVvbmUgdGhhdCBoYXMgdGhlIGtleSBzZW50IHRoaXMuIE9uZQ0KPiA+ ID4gPiBkb24ndA0KPiA+ID4gPiBrbm93IHRoYXQgaXQgY29tZXMgZnJvbSBhIHBhcnRpY3VsYXIg ZW5kcG9pbnQuIA0KPiA+ID4gPiANCj4gPiA+ID4gLSBDb25maWRlbnRpYWxpdHkgd2hlbiBncm91 cCBtZW1iZXJzaGlwIGNoYW5nZXM6IFNvIHdpbGwgU0ZSQU1FIGtleWluZw0KPiA+ID4gPiBzdXBw b3J0IGENCj4gPiA+ID4gdXNlIGNhc2Ugd2hlcmUgb25seSB0aGUgY3VycmVudCBzZXQgb2YgbWVt YmVycyBpbiBhIGNvbmZlcmVuY2UgY2FuDQo+ID4gPiA+IGRlY3J5cHQgdGhlDQo+ID4gPiA+IG1l ZGlhIGFuZCBvbmUgcmVrZXkgdGhlIG1lZGlhIHNlc3Npb24ga2V5IGZvciBlYWNoIHRpbWUgdGhl IG1lbWJlcnNoaXANCj4gPiA+ID4gY2hhbmdlcz8NCj4gPiA+ID4gUEVSQyBkbyBzdXBwb3J0IHRo aXMsIHdpbGwgU0ZSQU1FPyANCj4gPiA+ID4gDQo+ID4gPiA+IFRoZXJlIGFyZSBsaWtlbHkgbW9y ZSBxdWVzdGlvbnMgdGhhdCBuZWVkcyBkaXNjdXNzaW9uLiBUaGUgUEVSQw0KPiA+ID4gPiBkaXNj dXNzaW9uIGlzIGENCj4gPiA+ID4gZ29vZCBzdGFydGluZyBwb2ludCwgYnV0IEkgdGhpbmsgd2hl biBnb2luZyB0cmFuc3BvcnQgYWdub3N0aWMgc29tZSBvZg0KPiA+ID4gPiB0aGUNCj4gPiA+ID4g aXNzdWVzIG5lZWRzIHRvIGJlIG1vcmUgY2xlYXJseSBkaXNjdXNzZWQgYXMgdGhlIFJUUCB0cmFu c3BvcnQgY2FuIGhhdmUNCj4gPiA+ID4gYWZmZWN0ZWQNCj4gPiA+ID4gaG93IGl0IHdhcyBkaXNj dXNzZWQsIGFuZCB3aGF0IHJlbGlhbmNlIG9uIGV4aXN0aW5nIG1lY2hhbmlzbS4gV2hpY2ggZm9y DQo+ID4gPiA+IFNGUkFNRQ0KPiA+ID4gPiBsaWtlbHkgcmVxdWlyZSBhIGdlbmVyYWwgZGlzY3Vz c2lvbiBhbmQgdGhlbiByZXF1aXJlbWVudHMgb24gdGhlDQo+ID4gPiA+IHRyYW5zcG9ydCBhbmQN Cj4gPiA+ID4gaW52b3ZsZWQgZW5kcG9pbnRzIGFuZCBTRlUgdG8gYWNjb21wbGlzaCBtaXRpZ2F0 aW9ucy4gQW5kIHRodXMgYWxzbyB3aGF0DQo+ID4gPiA+IHRoZQ0KPiA+ID4gPiByaXNrcyBhcmUg b2YgaGF2aW5nIG5vIG1pdGlnYXRpb24gaW4gcGxhY2UuIA0KPiA+ID4gPiANCj4gPiA+ID4gSSB3 b3VsZCByZWFsbHkgcHJvcG9zZSB0aGF0IFNGUkFNRSBpcyBjaGFydGVyZWQgd2l0aCBwdWJsaXNo aW5nIGENCj4gPiA+ID4gc2VjdXJpdHkNCj4gPiA+ID4gY29uc2lkZXJhdGlvbiBhbmQgdGhyZWF0 IG1vZGVsIGRvY3VtZW50IHRoYXQgaXMgc2VwZXJhdGUgZnJvbSB0aGUNCj4gPiA+ID4gc29sdXRp b24gdG8NCj4gPiA+ID4gZ2l2ZSB0aGlzIHRvcGljIGZ1bGwgZm9jdXMuIFRoZSBzb2x1dGlvbiB3 aWxsIG9mIG5lY2Vzc2l0eSBuZWVkIHRvDQo+ID4gPiA+IHJlZmVyZW5jZQ0KPiA+ID4gPiB0aGF0 IGFuZCBkb2N1bWVudCB3aGF0IG1pZ2l0YWd0aW9ucyB0aGF0IGV4aXN0cyBpbiB0aGUgU0ZSQU1F IGxheWVyIGFuZA0KPiA+ID4gPiB3aGF0DQo+ID4gPiA+IGJlY29tZXMgcmVxdWlyZW1lbnRzIG9u IHRoZSB0cmFuc3BvcnQuIA0KPiA+ID4gPiANCj4gPiA+ID4gQ2hlZXJzDQo+ID4gPiA+IA0KPiA+ ID4gPiBNYWdudXMgV2VzdGVybHVuZCANCj4gPiA+ID4gDQo+ID4gPiA+IA0KPiA+ID4gPiAtLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tDQo+ID4gPiA+IE5ldHdvcmtzLCBFcmljc3NvbiBSZXNlYXJjaA0KPiA+ID4gPiAt LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tDQo+ID4gPiA+IEVyaWNzc29uIEFCICAgICAgICAgICAgICAgICB8IFBob25l ICArNDYgMTAgNzE0ODI4Nw0KPiA+ID4gPiBUb3JzaGFtbnNnYXRhbiAyMyAgICAgICAgICAgfCBN b2JpbGUgKzQ2IDczIDA5NDkwNzkNCj4gPiA+ID4gU0UtMTY0IDgwIFN0b2NraG9sbSwgU3dlZGVu IHwgbWFpbHRvOiBtYWdudXMud2VzdGVybHVuZEBlcmljc3Nvbi5jb20NCj4gPiA+ID4gLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLQ0KPiA+ID4gPiANCj4gPiA+ID4gDQotLSANCkNoZWVycw0KDQpNYWdudXMgV2VzdGVy bHVuZCANCg0KDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQpOZXR3b3JrcywgRXJpY3Nzb24gUmVzZWFyY2gNCi0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0NCkVyaWNzc29uIEFCICAgICAgICAgICAgICAgICB8IFBob25lICArNDYgMTAg NzE0ODI4Nw0KVG9yc2hhbW5zZ2F0YW4gMjMgICAgICAgICAgIHwgTW9iaWxlICs0NiA3MyAwOTQ5 MDc5DQpTRS0xNjQgODAgU3RvY2tob2xtLCBTd2VkZW4gfCBtYWlsdG86IG1hZ251cy53ZXN0ZXJs dW5kQGVyaWNzc29uLmNvbQ0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KDQoNCg== From nobody Mon Aug 31 08:40:51 2020 Return-Path: X-Original-To: sframe@ietfa.amsl.com Delivered-To: sframe@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F8803A161E for ; Mon, 31 Aug 2020 08:40:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=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=ipv-sx.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 bvzZxx6EpFmj for ; Mon, 31 Aug 2020 08:40:40 -0700 (PDT) Received: from mail-qk1-x729.google.com (mail-qk1-x729.google.com [IPv6:2607:f8b0:4864:20::729]) (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 682093A163F for ; Mon, 31 Aug 2020 08:40:38 -0700 (PDT) Received: by mail-qk1-x729.google.com with SMTP id o64so6475946qkb.10 for ; Mon, 31 Aug 2020 08:40:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ipv-sx.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=rAE6OwkwC75tsYTi9hxQQavng3YWDDaQpR0yCqymdH0=; b=MjQGQCMP6IGtlkns9CKsneCTx6tbvpN0011wkCPQ2uaKoRVpk757OwhiNwUvwDdpf+ M9DxbM+cWRFIPufrwLbmSOiapi5cV1DQkKD2kFLyf1n80lD9Nmw8yvuRPIZ1cqF6DHdw Gcoju18JMOCM2FM7Ud/0eZ2/oeYMjRPvp0Z2/0a9TryRFAkvGUgTc03ytfQt6iCf2Tui CUFsBKQzDVERD/muPZ14SXHOnx+zHkhycTzym9vzbHBwsAxAsw16qxuvMoXAyGFyAHQ8 ddmJlhqgy8CKwswaqd8F08it3KoiU9zCPaful9unh/7IV2oBxk//7hdfP/jmx2ayldgl EHQA== 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=rAE6OwkwC75tsYTi9hxQQavng3YWDDaQpR0yCqymdH0=; b=hAr4+AsilbNBmtU+fBfHMG1xtBhOnqhmaxyBSW3v7LXP4+leaB/ABy/4agWIh1ChWj KVxofEIkKjH6Yt4gdVj0FlfgNrXxOP5CNDQskrzBzqKx7LTr51rIi2uEAoCG5KeDlbIi ycLWb9SLq/AG5aphWxwM/nh+p1TPygyBA8S2q70xdStT6s2kSEu/BiEI7TQRNz7Q30S9 7zLDpbuJzTCFEMNk4JPwn6ij61pOf/be1UboE3wR+s+LFfJXOUIImS5vNh17xriSnDMv TFcPfgzIGQKHaKZHuPVR1FltbD2eW8h+HxRHdLtt8dTAfvLsF18XQIrcGDvLn/i/3VZ2 04vg== X-Gm-Message-State: AOAM5306W8JVx9ZJ12eGCABHxlu+qK3Ke9qvPh4cidb/5sfdLs6cHPnY t1FVrtG3ZtCzIMNEuPEqlzeNpKMvem67Qw8GEzhbnw== X-Google-Smtp-Source: ABdhPJyv7bKwL8Rg908LpkNcs4Ufpoh88Q7un5O9Vj5CDpGm6xfqCMTLjTpqlo52PiZOU1DTV4ZaSwQHnsIqeMjYW3s= X-Received: by 2002:a05:620a:125b:: with SMTP id a27mr1952520qkl.371.1598888437288; Mon, 31 Aug 2020 08:40:37 -0700 (PDT) MIME-Version: 1.0 References: <69181ed1-d72a-99de-8b4d-9e10276ced91@gmail.com> <771e108a9f25c1bec04d5fcdad58eb55bbb1533d.camel@ericsson.com> In-Reply-To: From: Richard Barnes Date: Mon, 31 Aug 2020 11:40:09 -0400 Message-ID: To: Magnus Westerlund Cc: "Alex.GOUAILLARD@cosmosoftware.io" , "ben@nostrum.com" , "emadomara=40google.com@dmarc.ietf.org" , "dispatch@ietf.org" , "sframe@ietf.org" , "sergio.garcia.murillo@gmail.com" Content-Type: multipart/alternative; boundary="00000000000057254505ae2e3930" Archived-At: Subject: Re: [Sframe] [dispatch] SFRame Next Steps (was SFrame proposed WG charter) X-BeenThere: sframe@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Aug 2020 15:40:49 -0000 --00000000000057254505ae2e3930 Content-Type: text/plain; charset="UTF-8" Hi Magnus, I think the intent here is to have a mechanism that provides a subset of the security properties required for a given scenario, but which can be augmented with additional mechanisms to provide the rest. For example, even in the most obvious SFrame+SRTP case, there's a division of labor between the two protocols, where SFrame only protects content, and SRTP also protects the RTP header and guards against reply by network attackers. So in a sense it is an intersection (in that it does something that is needed by all the use cases), but it might need other things to provide all the properties you need in a given scenario. --Richard On Mon, Aug 31, 2020 at 10:06 AM Magnus Westerlund < magnus.westerlund@ericsson.com> wrote: > Hi, > > Thanks for working on addressing my comments when on vacation. > > I think you mostly arravied at a good place. However, I would like to make > one > remark about the added language. > > When it comes to threat models it can't be the intersection of threats > across > those that occur in the intended usages, it needs to be the union of > threats. > The formulation added implies intersection to me. > > Cheers > > Magnus > > On Wed, 2020-08-12 at 11:11 -0400, Richard Barnes wrote: > > Hey all, > > > > I agree that all of this stuff is valuable to capture somewhere. In the > > interest of keeping the charter fairly succinct, I've added the > following: > > > > """ > > The SFrame specification will detail the specific security properties > that the > > encapsulation provides, and discuss their implications under common usage > > scenarios / threat models. > > """ > > > > With that, I think that all the comments we've gotten so far have been > > addressed. > > > > --Richard > > > > > > On Fri, Aug 7, 2020 at 11:51 PM Alexandre GOUAILLARD < > > Alex.GOUAILLARD@cosmosoftware.io> wrote: > > > guys, > > > > > > sorry for jumping in so late, quarantine here is very strict. > > > > > > We had long discussions about this specific point ahead of the draft > > > submission. > > > We had reached the following consensus: > > > - there are multiple usage of media over the internet, e.g. > conferencing and > > > streaming/broadcast > > > - they have very different threat/trust models, with different > solutions > > > implemented today (transport layer E / E2EE / DRM / Encrypted Media > > > Extentions / ...) > > > - they all can benefit from SFrame > > > > > > PERC was, by design, limited to RTP and to Conferencing. Many other > use case > > > coul benefit from Enhanced Privacy. > > > > > > We concluded that it would be better to keep SFrame (the media > encryption > > > part, equivalent to PERC double conceptually), and to have separated > > > documents that describe the threat models and the corresponding key > > > exchange, signaling and system level decision for each use case. Emad > had > > > taken an action item for example to make two additional documents to > > > describe the Video Conferencing use case, and how SFrame could be used > in > > > conjunction with MLS to address that specific use case. Someone else > could > > > take the different use case of the Browsers (which have a specific > trust > > > model) and make a document showing how SFrame con work with Insertable > Frame > > > API (and likely some more) to address that use case. CoSMo is > interested in > > > doing the same thing for Real-Time streaming/Broadcasting. > > > > > > I think it is a more reasonable approach as, even spending a lot of > time > > > brainstorming with everyone around the tabel including bernard, we > couldn't > > > think about one solution to fit all the different "media over > internet"'s > > > threat model. In my mind, each case should first have an informal > document > > > to define scope and threat model, and subsequent document to define the > > > corresponding specifications. > > > - Secure Conferencing Threat model (emad and co.) > > > - Secure Conferencing Signalling using MLS (emad and co.) > > > - Secure Conferencing using MLS In the browser (contributed by w3c > people) > > > > > > Magnus, what do you think? > > > > > > Regards, > > > > > > Dr. ALex. > > > > > > > > > > > > On Fri, Aug 7, 2020 at 2:02 AM Emad Omara < > > > emadomara=40google.com@dmarc.ietf.org> wrote: > > > > Thanks Magnus. I like the idea to explicitly call out the threat > model, I > > > > think it will be good foundations that control all future design > > > > decisions, however I'm not sure if the charter is the right place to > call > > > > this out. I'd recommend having a separate document that describes the > > > > system architecture, goals and threat model. What do you think? > > > > > > > > Emad > > > > > > > > On Thu, Aug 6, 2020 at 1:56 AM Magnus Westerlund < > > > > magnus.westerlund@ericsson.com> wrote: > > > > > Hi, > > > > > > > > > > On Wed, 2020-08-05 at 22:15 +0200, Sergio Garcia Murillo wrote: > > > > > > But shouldn't the "delayed media" attack still be transport > agnostic? > > > > > I > > > > > > mean, this can happen on QUIC and WebRTC SFUs. > > > > > > > > > > Sorry if I gave the impression that it is not transport agnostic. > It is > > > > > use case > > > > > dependent, any use case that isn't point to point, where there is > more > > > > > than one > > > > > entity that can intentionally remove SFRAME creating gaps in the > SFRAME > > > > > sequence. In a point to point scenario one can correlate transport > > > > > losses with > > > > > SFRAME gaps to know give a reasonably strong mitigation against any > > > > > third party > > > > > removing SFRAMEs or delaying them. That is much harder in a > centralized > > > > > conference with one or more SFU. > > > > > > > > > > > > > > > > > Anyway, I agree that while SFrame is transport agnostic, the > chapter > > > > > > should not ignore the interactions with webrtc/quic and we must > > > > > ensure > > > > > > that we provide a complete working solution regardless of the > > > > > transport. > > > > > > If we identify that any further working items are required for a > > > > > > particular transport, we should at liaise with the appropriate > > > > > working > > > > > > group for providing a solution. > > > > > > > > > > My main point is that SFRAME actually needs to discuss the threat > model > > > > > for the > > > > > use cases it intendes to solve. And the mitigation can potentially > > > > > include > > > > > functionality on the transport level. But the risks to media > security in > > > > > centralized conferencing needs to be discussed. And centralized > > > > > conferencing > > > > > will still have the semi-trusted SFUs and all the rest of the third > > > > > parties in > > > > > addition to the end-points. > > > > > > > > > > Also what properties one have around end-points invited into the > > > > > conference has > > > > > a number of question around security properties that needs to be > > > > > discussed and > > > > > documented. Some examples that I know are relevant: > > > > > > > > > > - Source authentication: SRTP unless one use TESLA (which isn't > really > > > > > used) > > > > > does only provided the property: Someone that has the key sent > this. One > > > > > don't > > > > > know that it comes from a particular endpoint. > > > > > > > > > > - Confidentiality when group membership changes: So will SFRAME > keying > > > > > support a > > > > > use case where only the current set of members in a conference can > > > > > decrypt the > > > > > media and one rekey the media session key for each time the > membership > > > > > changes? > > > > > PERC do support this, will SFRAME? > > > > > > > > > > There are likely more questions that needs discussion. The PERC > > > > > discussion is a > > > > > good starting point, but I think when going transport agnostic > some of > > > > > the > > > > > issues needs to be more clearly discussed as the RTP transport can > have > > > > > affected > > > > > how it was discussed, and what reliance on existing mechanism. > Which for > > > > > SFRAME > > > > > likely require a general discussion and then requirements on the > > > > > transport and > > > > > invovled endpoints and SFU to accomplish mitigations. And thus > also what > > > > > the > > > > > risks are of having no mitigation in place. > > > > > > > > > > I would really propose that SFRAME is chartered with publishing a > > > > > security > > > > > consideration and threat model document that is seperate from the > > > > > solution to > > > > > give this topic full focus. The solution will of necessity need to > > > > > reference > > > > > that and document what migitagtions that exists in the SFRAME > layer and > > > > > what > > > > > becomes requirements on the transport. > > > > > > > > > > Cheers > > > > > > > > > > Magnus Westerlund > > > > > > > > > > > > > > > > ---------------------------------------------------------------------- > > > > > Networks, Ericsson Research > > > > > > ---------------------------------------------------------------------- > > > > > Ericsson AB | Phone +46 10 7148287 > > > > > Torshamnsgatan 23 | Mobile +46 73 0949079 > > > > > SE-164 80 Stockholm, Sweden | mailto: > magnus.westerlund@ericsson.com > > > > > > ---------------------------------------------------------------------- > > > > > > > > > > > -- > Cheers > > Magnus Westerlund > > > ---------------------------------------------------------------------- > Networks, Ericsson Research > ---------------------------------------------------------------------- > Ericsson AB | Phone +46 10 7148287 > Torshamnsgatan 23 | Mobile +46 73 0949079 > SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com > ---------------------------------------------------------------------- > > > --00000000000057254505ae2e3930 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Magnus,

I think the inten= t here is to have a mechanism that provides a subset of the security proper= ties required for a given scenario, but which can be augmented with additio= nal mechanisms to provide the rest.=C2=A0 For example, even in the most obv= ious SFrame+SRTP case, there's a division of labor between the two prot= ocols, where SFrame only protects content, and SRTP also protects the RTP h= eader and guards against reply by network attackers.

So in a sense it is an intersection (in that it does something that is n= eeded by all the use cases), but it might need other things to provide all = the properties you need in a given scenario.

--Ric= hard

On Mon, Aug 31, 2020 at 10:06 AM Magnus Westerlund <magnus.westerlund@ericsson.com>= ; wrote:
Hi,

Thanks for working on addressing my comments when on vacation.

I think you mostly arravied at a good place. However, I would like to make = one
remark about the added language.

When it comes to threat models it can't be the intersection of threats = across
those that occur in the intended usages, it needs to be the union of threat= s.
The formulation added implies intersection to me.

Cheers

Magnus

On Wed, 2020-08-12 at 11:11 -0400, Richard Barnes wrote:
> Hey all,
>
> I agree that all of this stuff is valuable to capture somewhere.=C2=A0= In the
> interest of keeping the charter fairly succinct, I've added the fo= llowing:
>
> """
> The SFrame specification will detail the specific security properties = that the
> encapsulation provides, and discuss their implications under common us= age
> scenarios / threat models.
> """
>
> With that, I think that all the comments we've gotten so far have = been
> addressed.
>
> --Richard
>
>
> On Fri, Aug 7, 2020 at 11:51 PM Alexandre GOUAILLARD <
> = Alex.GOUAILLARD@cosmosoftware.io> wrote:
> > guys,
> >
> > sorry for jumping in so late, quarantine here is very strict.
> >
> > We had long discussions about this specific point ahead of the dr= aft
> > submission.
> > We had reached the following consensus:
> > - there are multiple usage of media over the internet, e.g. confe= rencing and
> > streaming/broadcast
> > - they have very different threat/trust models, with different so= lutions
> > implemented today (transport layer E / E2EE / DRM / Encrypted Med= ia
> > Extentions / ...)
> > - they all can benefit from SFrame
> >
> > PERC was, by design, limited to RTP and to Conferencing. Many oth= er use case
> > coul benefit from Enhanced Privacy.
> >
> > We concluded that it would be better to keep SFrame (the media en= cryption
> > part, equivalent to PERC double conceptually), and to have separa= ted
> > documents that describe the threat models and the corresponding k= ey
> > exchange, signaling and system level decision for each use case. = Emad had
> > taken an action item for example to make two additional documents= to
> > describe the Video Conferencing use case, and how SFrame could be= used in
> > conjunction with MLS to address that specific use case. Someone e= lse could
> > take the different use case of the Browsers (which have a specifi= c trust
> > model) and make a document showing how SFrame con work with Inser= table Frame
> > API (and likely some more) to address that use case. CoSMo is int= erested in
> > doing the same thing for Real-Time streaming/Broadcasting.
> >
> > I think it is a more reasonable approach as, even spending a lot = of time
> > brainstorming with everyone around the tabel including bernard, w= e couldn't
> > think about one solution to fit all the different "media ove= r internet"'s
> > threat model. In my mind, each case should first have an informal= document
> > to define scope and threat model, and subsequent document to defi= ne the
> > corresponding specifications.
> > - Secure Conferencing Threat model (emad and co.)
> > - Secure Conferencing Signalling using MLS (emad and co.)
> > - Secure Conferencing using MLS In the browser (contributed by w3= c people)
> >
> > Magnus, what do you think?
> >
> > Regards,
> >
> > Dr. ALex.
> >
> >
> >
> > On Fri, Aug 7, 2020 at 2:02 AM Emad Omara <
> > emadomara=3D40google.com@dmarc.ietf.org> wrote:
> > > Thanks Magnus. I like the idea to explicitly call out the th= reat model, I
> > > think it will be good foundations that control all future de= sign
> > > decisions, however I'm not sure if the charter is the ri= ght place to call
> > > this out. I'd recommend having a separate document that = describes the
> > > system architecture, goals and threat model. What do you thi= nk?
> > >
> > > Emad
> > >
> > > On Thu, Aug 6, 2020 at 1:56 AM Magnus Westerlund <
> > > magnus.westerlund@ericsson.com> wrote:
> > > > Hi,
> > > >
> > > > On Wed, 2020-08-05 at 22:15 +0200, Sergio Garcia Murill= o wrote:
> > > > > But shouldn't the "delayed media" at= tack still be transport agnostic?
> > > > I
> > > > > mean, this can happen on QUIC and WebRTC SFUs.
> > > >
> > > > Sorry if I gave the impression that it is not transport= agnostic. It is
> > > > use case
> > > > dependent, any use case that isn't point to point, = where there is more
> > > > than one
> > > > entity that can intentionally remove SFRAME creating ga= ps in the SFRAME
> > > > sequence. In a point to point scenario one can correlat= e transport
> > > > losses with
> > > > SFRAME gaps to know give a reasonably strong mitigation= against any
> > > > third party
> > > > removing SFRAMEs or delaying them. That is much harder = in a centralized
> > > > conference with one or more SFU.
> > > >
> > > > >
> > > > > Anyway, I agree that while SFrame is transport agn= ostic, the chapter
> > > > > should not ignore the interactions with webrtc/qui= c and we must
> > > > ensure
> > > > > that we provide a complete working solution regard= less of the
> > > > transport.
> > > > > If we identify that any further working items are = required for a
> > > > > particular transport, we should at liaise with the= appropriate
> > > > working
> > > > > group for providing a solution.
> > > >
> > > > My main point is that SFRAME actually needs to discuss = the threat model
> > > > for the
> > > > use cases it intendes to solve. And the mitigation can = potentially
> > > > include
> > > > functionality on the transport level. But the risks to = media security in
> > > > centralized conferencing needs to be discussed. And cen= tralized
> > > > conferencing
> > > > will still have the semi-trusted SFUs and all the rest = of the third
> > > > parties in
> > > > addition to the end-points.
> > > >
> > > > Also what properties one have around end-points invited= into the
> > > > conference has
> > > > a number of question around security properties that ne= eds to be
> > > > discussed and
> > > > documented. Some examples that I know are relevant:
> > > >
> > > > - Source authentication: SRTP unless one use TESLA (whi= ch isn't really
> > > > used)
> > > > does only provided the property: Someone that has the k= ey sent this. One
> > > > don't
> > > > know that it comes from a particular endpoint.
> > > >
> > > > - Confidentiality when group membership changes: So wil= l SFRAME keying
> > > > support a
> > > > use case where only the current set of members in a con= ference can
> > > > decrypt the
> > > > media and one rekey the media session key for each time= the membership
> > > > changes?
> > > > PERC do support this, will SFRAME?
> > > >
> > > > There are likely more questions that needs discussion. = The PERC
> > > > discussion is a
> > > > good starting point, but I think when going transport a= gnostic some of
> > > > the
> > > > issues needs to be more clearly discussed as the RTP tr= ansport can have
> > > > affected
> > > > how it was discussed, and what reliance on existing mec= hanism. Which for
> > > > SFRAME
> > > > likely require a general discussion and then requiremen= ts on the
> > > > transport and
> > > > invovled endpoints and SFU to accomplish mitigations. A= nd thus also what
> > > > the
> > > > risks are of having no mitigation in place.
> > > >
> > > > I would really propose that SFRAME is chartered with pu= blishing a
> > > > security
> > > > consideration and threat model document that is seperat= e from the
> > > > solution to
> > > > give this topic full focus. The solution will of necess= ity need to
> > > > reference
> > > > that and document what migitagtions that exists in the = SFRAME layer and
> > > > what
> > > > becomes requirements on the transport.
> > > >
> > > > Cheers
> > > >
> > > > Magnus Westerlund
> > > >
> > > >
> > > > -------------------------------------------------------= ---------------
> > > > Networks, Ericsson Research
> > > > -------------------------------------------------------= ---------------
> > > > Ericsson AB=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0| Phone=C2=A0 +46 10 7148287
> > > > Torshamnsgatan 23=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0| Mobile +46 73 0949079
> > > > SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericss= on.com
> > > > -------------------------------------------------------= ---------------
> > > >
> > > >
--
Cheers

Magnus Westerlund


----------------------------------------------------------------------
Networks, Ericsson Research
----------------------------------------------------------------------
Ericsson AB=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| = Phone=C2=A0 +46 10 7148287
Torshamnsgatan 23=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| Mobile +46 73 0= 949079
SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com
----------------------------------------------------------------------


--00000000000057254505ae2e3930-- From nobody Mon Aug 31 12:27:27 2020 Return-Path: X-Original-To: sframe@ietfa.amsl.com Delivered-To: sframe@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C4F23A1903; Mon, 31 Aug 2020 12:27:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, 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=gmail.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 NqaytFwrzO88; Mon, 31 Aug 2020 12:27:21 -0700 (PDT) Received: from mail-lj1-x22c.google.com (mail-lj1-x22c.google.com [IPv6:2a00:1450:4864:20::22c]) (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 90DC03A1900; Mon, 31 Aug 2020 12:27:20 -0700 (PDT) Received: by mail-lj1-x22c.google.com with SMTP id w14so8057496ljj.4; Mon, 31 Aug 2020 12:27:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=GGG5x5NZ0c31nkuiFGU60jF8vwJkoSCFAyW3tOPG88I=; b=fN9vNZc8JPeYVjqYcTpycaICydZekXOZ+CKmWyWfsOZamj6Yk5QwxLCj/lSCZpdqcs 34T826vaQYZXr/CM8Rx+8vzVuJY2XJA39OE1imqnqEg+x4CG71FFiO190QnTfzB87gER 29WdXiSyP6gdL8s8dR9lsIuufSSYUrLNdadgftYrdag3olE5dy0dKoT/tht8XD5DZAed nqt7WhlfJFJSwUxkJ+rNwI+UPDjcU87kWWkjSQLn15+r7/PDekrOp8oXlohj+Sqosj4A POaoBR/sqpBXvd0f4tC0DbkzNwAeazoJUbqg2lrHRZmWQ+XbkpatbUYE0NKAZxNUdL/9 laKw== 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=GGG5x5NZ0c31nkuiFGU60jF8vwJkoSCFAyW3tOPG88I=; b=lZLyZ/hkjT+U+XLhIgCgElyKtH9I7S5vXA0nsqzDmddva274B881lAHzk5wpCZjFuS Ua8oZcMo+TMV9Mep7qvhDZMAThfRHMOJFHvQ6V7RX2mSj8wSP2Q36pRKtgdyojmAjzsa wSeDkfXw8Fn5XNEZldIpgSNqXoSRbgKcYiwEnpgmnX6A76d9OdHKkI4dPGClthZalSXR uExgiskl+WCNBVL1DS8Q3I4YbrmU4NGlMgy8n87W8wE0opjMmG3QY8QJRUMOwwWOzSnu 2sM20+814Lz/RcgcN3rSQLR5m5RGoII8QMX7IL6fCXXFAOgP8/u476JpKtchr8t02OjP jV9A== X-Gm-Message-State: AOAM5321phbRxMCVJyQxpPQaJlMDx58V/xjSc28VWpIO6AK9YaTIVu1i rfPSN2AfymSqJQ+bUGk96fLqf143LhgZvCt1ob4= X-Google-Smtp-Source: ABdhPJzzDQqiWpy9PZW6dJ+qS0Pc/DB/GvgsqXhVibFZEmkZXHUk1fePtUMdDiPqg7h+aDUHL9P3eqCe5vh8WGicBn4= X-Received: by 2002:a2e:6819:: with SMTP id c25mr1340827lja.187.1598902038388; Mon, 31 Aug 2020 12:27:18 -0700 (PDT) MIME-Version: 1.0 References: <69181ed1-d72a-99de-8b4d-9e10276ced91@gmail.com> <771e108a9f25c1bec04d5fcdad58eb55bbb1533d.camel@ericsson.com> In-Reply-To: From: Bernard Aboba Date: Mon, 31 Aug 2020 12:27:07 -0700 Message-ID: To: Richard Barnes Cc: Magnus Westerlund , "emadomara=40google.com@dmarc.ietf.org" , "ben@nostrum.com" , "dispatch@ietf.org" , "sframe@ietf.org" , "sergio.garcia.murillo@gmail.com" , "Alex.GOUAILLARD@cosmosoftware.io" Content-Type: multipart/alternative; boundary="00000000000007618e05ae31647f" Archived-At: Subject: Re: [Sframe] [dispatch] SFRame Next Steps (was SFrame proposed WG charter) X-BeenThere: sframe@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Aug 2020 19:27:23 -0000 --00000000000007618e05ae31647f Content-Type: text/plain; charset="UTF-8" Richard said: "in the most obvious SFrame+SRTP case, there's a division of labor between the two protocols, " [BA] There is also an interaction between E2E encryption and packetization that needs to be captured somewhere. In SFrame, the packetization model is potentially different from PERC, because the SFrame packetizer may not have visibility into the E2E encrypted payload (e.g. the packetizer may not have access to the cleartext payload). The implication is that the information needed to packetize the E2E encrypted frame (e.g. the metadata) needs to be provided to the packetizer. This info must be sufficient to fill in the RTP header fields as well as RTP header extensions, including those RTP header extensions used by an SFU for forwarding (e.g. frame-marking or Dependency Descriptor). I'd note that the current SFrame draft does not address this yet, except for a figure including a "payload header" in section 1. It is my understanding that the "Payload Header" represents info provided in the clear (such as the VP8 header), which is needed by the packetizer. Implementations that have encrypted this field or have not provided what was expected (e.g. attempts to utilize the H.264/AVC codec) have encountered E2E encryption failures. One approach to addressing this is to define a "generic packetizer" for a transport that will be able to packetize and depacketize the E2E encrypted frame in any codec. If that work is indeed needed, then it should be described somewhere. On Mon, Aug 31, 2020 at 8:41 AM Richard Barnes wrote: > Hi Magnus, > > I think the intent here is to have a mechanism that provides a subset of > the security properties required for a given scenario, but which can be > augmented with additional mechanisms to provide the rest. For example, > even in the most obvious SFrame+SRTP case, there's a division of labor > between the two protocols, where SFrame only protects content, and SRTP > also protects the RTP header and guards against reply by network attackers. > > So in a sense it is an intersection (in that it does something that is > needed by all the use cases), but it might need other things to provide all > the properties you need in a given scenario. > > --Richard > > On Mon, Aug 31, 2020 at 10:06 AM Magnus Westerlund < > magnus.westerlund@ericsson.com> wrote: > >> Hi, >> >> Thanks for working on addressing my comments when on vacation. >> >> I think you mostly arravied at a good place. However, I would like to >> make one >> remark about the added language. >> >> When it comes to threat models it can't be the intersection of threats >> across >> those that occur in the intended usages, it needs to be the union of >> threats. >> The formulation added implies intersection to me. >> >> Cheers >> >> Magnus >> >> On Wed, 2020-08-12 at 11:11 -0400, Richard Barnes wrote: >> > Hey all, >> > >> > I agree that all of this stuff is valuable to capture somewhere. In the >> > interest of keeping the charter fairly succinct, I've added the >> following: >> > >> > """ >> > The SFrame specification will detail the specific security properties >> that the >> > encapsulation provides, and discuss their implications under common >> usage >> > scenarios / threat models. >> > """ >> > >> > With that, I think that all the comments we've gotten so far have been >> > addressed. >> > >> > --Richard >> > >> > >> > On Fri, Aug 7, 2020 at 11:51 PM Alexandre GOUAILLARD < >> > Alex.GOUAILLARD@cosmosoftware.io> wrote: >> > > guys, >> > > >> > > sorry for jumping in so late, quarantine here is very strict. >> > > >> > > We had long discussions about this specific point ahead of the draft >> > > submission. >> > > We had reached the following consensus: >> > > - there are multiple usage of media over the internet, e.g. >> conferencing and >> > > streaming/broadcast >> > > - they have very different threat/trust models, with different >> solutions >> > > implemented today (transport layer E / E2EE / DRM / Encrypted Media >> > > Extentions / ...) >> > > - they all can benefit from SFrame >> > > >> > > PERC was, by design, limited to RTP and to Conferencing. Many other >> use case >> > > coul benefit from Enhanced Privacy. >> > > >> > > We concluded that it would be better to keep SFrame (the media >> encryption >> > > part, equivalent to PERC double conceptually), and to have separated >> > > documents that describe the threat models and the corresponding key >> > > exchange, signaling and system level decision for each use case. Emad >> had >> > > taken an action item for example to make two additional documents to >> > > describe the Video Conferencing use case, and how SFrame could be >> used in >> > > conjunction with MLS to address that specific use case. Someone else >> could >> > > take the different use case of the Browsers (which have a specific >> trust >> > > model) and make a document showing how SFrame con work with >> Insertable Frame >> > > API (and likely some more) to address that use case. CoSMo is >> interested in >> > > doing the same thing for Real-Time streaming/Broadcasting. >> > > >> > > I think it is a more reasonable approach as, even spending a lot of >> time >> > > brainstorming with everyone around the tabel including bernard, we >> couldn't >> > > think about one solution to fit all the different "media over >> internet"'s >> > > threat model. In my mind, each case should first have an informal >> document >> > > to define scope and threat model, and subsequent document to define >> the >> > > corresponding specifications. >> > > - Secure Conferencing Threat model (emad and co.) >> > > - Secure Conferencing Signalling using MLS (emad and co.) >> > > - Secure Conferencing using MLS In the browser (contributed by w3c >> people) >> > > >> > > Magnus, what do you think? >> > > >> > > Regards, >> > > >> > > Dr. ALex. >> > > >> > > >> > > >> > > On Fri, Aug 7, 2020 at 2:02 AM Emad Omara < >> > > emadomara=40google.com@dmarc.ietf.org> wrote: >> > > > Thanks Magnus. I like the idea to explicitly call out the threat >> model, I >> > > > think it will be good foundations that control all future design >> > > > decisions, however I'm not sure if the charter is the right place >> to call >> > > > this out. I'd recommend having a separate document that describes >> the >> > > > system architecture, goals and threat model. What do you think? >> > > > >> > > > Emad >> > > > >> > > > On Thu, Aug 6, 2020 at 1:56 AM Magnus Westerlund < >> > > > magnus.westerlund@ericsson.com> wrote: >> > > > > Hi, >> > > > > >> > > > > On Wed, 2020-08-05 at 22:15 +0200, Sergio Garcia Murillo wrote: >> > > > > > But shouldn't the "delayed media" attack still be transport >> agnostic? >> > > > > I >> > > > > > mean, this can happen on QUIC and WebRTC SFUs. >> > > > > >> > > > > Sorry if I gave the impression that it is not transport agnostic. >> It is >> > > > > use case >> > > > > dependent, any use case that isn't point to point, where there is >> more >> > > > > than one >> > > > > entity that can intentionally remove SFRAME creating gaps in the >> SFRAME >> > > > > sequence. In a point to point scenario one can correlate transport >> > > > > losses with >> > > > > SFRAME gaps to know give a reasonably strong mitigation against >> any >> > > > > third party >> > > > > removing SFRAMEs or delaying them. That is much harder in a >> centralized >> > > > > conference with one or more SFU. >> > > > > >> > > > > > >> > > > > > Anyway, I agree that while SFrame is transport agnostic, the >> chapter >> > > > > > should not ignore the interactions with webrtc/quic and we must >> > > > > ensure >> > > > > > that we provide a complete working solution regardless of the >> > > > > transport. >> > > > > > If we identify that any further working items are required for >> a >> > > > > > particular transport, we should at liaise with the appropriate >> > > > > working >> > > > > > group for providing a solution. >> > > > > >> > > > > My main point is that SFRAME actually needs to discuss the threat >> model >> > > > > for the >> > > > > use cases it intendes to solve. And the mitigation can potentially >> > > > > include >> > > > > functionality on the transport level. But the risks to media >> security in >> > > > > centralized conferencing needs to be discussed. And centralized >> > > > > conferencing >> > > > > will still have the semi-trusted SFUs and all the rest of the >> third >> > > > > parties in >> > > > > addition to the end-points. >> > > > > >> > > > > Also what properties one have around end-points invited into the >> > > > > conference has >> > > > > a number of question around security properties that needs to be >> > > > > discussed and >> > > > > documented. Some examples that I know are relevant: >> > > > > >> > > > > - Source authentication: SRTP unless one use TESLA (which isn't >> really >> > > > > used) >> > > > > does only provided the property: Someone that has the key sent >> this. One >> > > > > don't >> > > > > know that it comes from a particular endpoint. >> > > > > >> > > > > - Confidentiality when group membership changes: So will SFRAME >> keying >> > > > > support a >> > > > > use case where only the current set of members in a conference can >> > > > > decrypt the >> > > > > media and one rekey the media session key for each time the >> membership >> > > > > changes? >> > > > > PERC do support this, will SFRAME? >> > > > > >> > > > > There are likely more questions that needs discussion. The PERC >> > > > > discussion is a >> > > > > good starting point, but I think when going transport agnostic >> some of >> > > > > the >> > > > > issues needs to be more clearly discussed as the RTP transport >> can have >> > > > > affected >> > > > > how it was discussed, and what reliance on existing mechanism. >> Which for >> > > > > SFRAME >> > > > > likely require a general discussion and then requirements on the >> > > > > transport and >> > > > > invovled endpoints and SFU to accomplish mitigations. And thus >> also what >> > > > > the >> > > > > risks are of having no mitigation in place. >> > > > > >> > > > > I would really propose that SFRAME is chartered with publishing a >> > > > > security >> > > > > consideration and threat model document that is seperate from the >> > > > > solution to >> > > > > give this topic full focus. The solution will of necessity need to >> > > > > reference >> > > > > that and document what migitagtions that exists in the SFRAME >> layer and >> > > > > what >> > > > > becomes requirements on the transport. >> > > > > >> > > > > Cheers >> > > > > >> > > > > Magnus Westerlund >> > > > > >> > > > > >> > > > > >> ---------------------------------------------------------------------- >> > > > > Networks, Ericsson Research >> > > > > >> ---------------------------------------------------------------------- >> > > > > Ericsson AB | Phone +46 10 7148287 >> > > > > Torshamnsgatan 23 | Mobile +46 73 0949079 >> > > > > SE-164 80 Stockholm, Sweden | mailto: >> magnus.westerlund@ericsson.com >> > > > > >> ---------------------------------------------------------------------- >> > > > > >> > > > > >> -- >> Cheers >> >> Magnus Westerlund >> >> >> ---------------------------------------------------------------------- >> Networks, Ericsson Research >> ---------------------------------------------------------------------- >> Ericsson AB | Phone +46 10 7148287 >> Torshamnsgatan 23 | Mobile +46 73 0949079 >> SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com >> ---------------------------------------------------------------------- >> >> >> -- > Sframe mailing list > Sframe@ietf.org > https://www.ietf.org/mailman/listinfo/sframe > --00000000000007618e05ae31647f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Richard said:=C2=A0

&q= uot;in the most obvious SFrame+SRTP case, there's a division of labor b= etween the two protocols,=C2=A0"

[BA] There i= s also an interaction between E2E encryption and packetization that needs t= o be captured somewhere. In SFrame, the packetization model is potentially = different from PERC, because the SFrame packetizer may not have visibility = into the E2E encrypted payload (e.g. the packetizer may not have access to = the cleartext payload).=C2=A0 The implication is that the information neede= d to packetize the E2E encrypted frame (e.g. the metadata) needs to be prov= ided to the packetizer.=C2=A0 This info must be sufficient to fill in the R= TP header fields as well as RTP header extensions, including those RTP head= er extensions used by an SFU for forwarding (e.g. frame-marking or Dependen= cy Descriptor).=C2=A0=C2=A0

I'd note that the = current SFrame draft does not address this yet, except for a figure includi= ng a "payload header" in section 1.=C2=A0 It is my understanding = that the "Payload Header" represents info provided in the clear (= such as the VP8 header), which is needed by the packetizer.=C2=A0 Implement= ations that have encrypted this field or have not provided what was expecte= d (e.g. attempts to utilize the H.264/AVC codec) have encountered E2E encry= ption failures.=C2=A0

One approach to addressing t= his is to define a "generic packetizer" for a transport that will= be able to packetize and depacketize the E2E encrypted frame in any codec.= =C2=A0 If that work is indeed needed, then it should be described somewhere= .=C2=A0

On Mon, Aug 31, 2020 at 8:41 AM Richard Barnes <rlb@i= pv.sx> wrote:
Hi Magnus,

I think the inte= nt here is to have a mechanism that provides a subset of the security prope= rties required for a given scenario, but which can be augmented with additi= onal mechanisms to provide the rest.=C2=A0 For example, even in the most ob= vious SFrame+SRTP case, there's a division of labor between the two pro= tocols, where SFrame only protects content, and SRTP also protects the RTP = header and guards against reply by network attackers.

<= div>So in a sense it is an intersection (in that it does something that is = needed by all the use cases), but it might need other things to provide all= the properties you need in a given scenario.

--Ri= chard

On Mon, Aug 31, 2020 at 10:06 AM Magnus Westerlund <magnus.westerlund@= ericsson.com> wrote:
Hi,

Thanks for working on addressing my comments when on vacation.

I think you mostly arravied at a good place. However, I would like to make = one
remark about the added language.

When it comes to threat models it can't be the intersection of threats = across
those that occur in the intended usages, it needs to be the union of threat= s.
The formulation added implies intersection to me.

Cheers

Magnus

On Wed, 2020-08-12 at 11:11 -0400, Richard Barnes wrote:
> Hey all,
>
> I agree that all of this stuff is valuable to capture somewhere.=C2=A0= In the
> interest of keeping the charter fairly succinct, I've added the fo= llowing:
>
> """
> The SFrame specification will detail the specific security properties = that the
> encapsulation provides, and discuss their implications under common us= age
> scenarios / threat models.
> """
>
> With that, I think that all the comments we've gotten so far have = been
> addressed.
>
> --Richard
>
>
> On Fri, Aug 7, 2020 at 11:51 PM Alexandre GOUAILLARD <
> = Alex.GOUAILLARD@cosmosoftware.io> wrote:
> > guys,
> >
> > sorry for jumping in so late, quarantine here is very strict.
> >
> > We had long discussions about this specific point ahead of the dr= aft
> > submission.
> > We had reached the following consensus:
> > - there are multiple usage of media over the internet, e.g. confe= rencing and
> > streaming/broadcast
> > - they have very different threat/trust models, with different so= lutions
> > implemented today (transport layer E / E2EE / DRM / Encrypted Med= ia
> > Extentions / ...)
> > - they all can benefit from SFrame
> >
> > PERC was, by design, limited to RTP and to Conferencing. Many oth= er use case
> > coul benefit from Enhanced Privacy.
> >
> > We concluded that it would be better to keep SFrame (the media en= cryption
> > part, equivalent to PERC double conceptually), and to have separa= ted
> > documents that describe the threat models and the corresponding k= ey
> > exchange, signaling and system level decision for each use case. = Emad had
> > taken an action item for example to make two additional documents= to
> > describe the Video Conferencing use case, and how SFrame could be= used in
> > conjunction with MLS to address that specific use case. Someone e= lse could
> > take the different use case of the Browsers (which have a specifi= c trust
> > model) and make a document showing how SFrame con work with Inser= table Frame
> > API (and likely some more) to address that use case. CoSMo is int= erested in
> > doing the same thing for Real-Time streaming/Broadcasting.
> >
> > I think it is a more reasonable approach as, even spending a lot = of time
> > brainstorming with everyone around the tabel including bernard, w= e couldn't
> > think about one solution to fit all the different "media ove= r internet"'s
> > threat model. In my mind, each case should first have an informal= document
> > to define scope and threat model, and subsequent document to defi= ne the
> > corresponding specifications.
> > - Secure Conferencing Threat model (emad and co.)
> > - Secure Conferencing Signalling using MLS (emad and co.)
> > - Secure Conferencing using MLS In the browser (contributed by w3= c people)
> >
> > Magnus, what do you think?
> >
> > Regards,
> >
> > Dr. ALex.
> >
> >
> >
> > On Fri, Aug 7, 2020 at 2:02 AM Emad Omara <
> > emadomara=3D40google.com@dmarc.ietf.org> wrote:
> > > Thanks Magnus. I like the idea to explicitly call out the th= reat model, I
> > > think it will be good foundations that control all future de= sign
> > > decisions, however I'm not sure if the charter is the ri= ght place to call
> > > this out. I'd recommend having a separate document that = describes the
> > > system architecture, goals and threat model. What do you thi= nk?
> > >
> > > Emad
> > >
> > > On Thu, Aug 6, 2020 at 1:56 AM Magnus Westerlund <
> > > magnus.westerlund@ericsson.com> wrote:
> > > > Hi,
> > > >
> > > > On Wed, 2020-08-05 at 22:15 +0200, Sergio Garcia Murill= o wrote:
> > > > > But shouldn't the "delayed media" at= tack still be transport agnostic?
> > > > I
> > > > > mean, this can happen on QUIC and WebRTC SFUs.
> > > >
> > > > Sorry if I gave the impression that it is not transport= agnostic. It is
> > > > use case
> > > > dependent, any use case that isn't point to point, = where there is more
> > > > than one
> > > > entity that can intentionally remove SFRAME creating ga= ps in the SFRAME
> > > > sequence. In a point to point scenario one can correlat= e transport
> > > > losses with
> > > > SFRAME gaps to know give a reasonably strong mitigation= against any
> > > > third party
> > > > removing SFRAMEs or delaying them. That is much harder = in a centralized
> > > > conference with one or more SFU.
> > > >
> > > > >
> > > > > Anyway, I agree that while SFrame is transport agn= ostic, the chapter
> > > > > should not ignore the interactions with webrtc/qui= c and we must
> > > > ensure
> > > > > that we provide a complete working solution regard= less of the
> > > > transport.
> > > > > If we identify that any further working items are = required for a
> > > > > particular transport, we should at liaise with the= appropriate
> > > > working
> > > > > group for providing a solution.
> > > >
> > > > My main point is that SFRAME actually needs to discuss = the threat model
> > > > for the
> > > > use cases it intendes to solve. And the mitigation can = potentially
> > > > include
> > > > functionality on the transport level. But the risks to = media security in
> > > > centralized conferencing needs to be discussed. And cen= tralized
> > > > conferencing
> > > > will still have the semi-trusted SFUs and all the rest = of the third
> > > > parties in
> > > > addition to the end-points.
> > > >
> > > > Also what properties one have around end-points invited= into the
> > > > conference has
> > > > a number of question around security properties that ne= eds to be
> > > > discussed and
> > > > documented. Some examples that I know are relevant:
> > > >
> > > > - Source authentication: SRTP unless one use TESLA (whi= ch isn't really
> > > > used)
> > > > does only provided the property: Someone that has the k= ey sent this. One
> > > > don't
> > > > know that it comes from a particular endpoint.
> > > >
> > > > - Confidentiality when group membership changes: So wil= l SFRAME keying
> > > > support a
> > > > use case where only the current set of members in a con= ference can
> > > > decrypt the
> > > > media and one rekey the media session key for each time= the membership
> > > > changes?
> > > > PERC do support this, will SFRAME?
> > > >
> > > > There are likely more questions that needs discussion. = The PERC
> > > > discussion is a
> > > > good starting point, but I think when going transport a= gnostic some of
> > > > the
> > > > issues needs to be more clearly discussed as the RTP tr= ansport can have
> > > > affected
> > > > how it was discussed, and what reliance on existing mec= hanism. Which for
> > > > SFRAME
> > > > likely require a general discussion and then requiremen= ts on the
> > > > transport and
> > > > invovled endpoints and SFU to accomplish mitigations. A= nd thus also what
> > > > the
> > > > risks are of having no mitigation in place.
> > > >
> > > > I would really propose that SFRAME is chartered with pu= blishing a
> > > > security
> > > > consideration and threat model document that is seperat= e from the
> > > > solution to
> > > > give this topic full focus. The solution will of necess= ity need to
> > > > reference
> > > > that and document what migitagtions that exists in the = SFRAME layer and
> > > > what
> > > > becomes requirements on the transport.
> > > >
> > > > Cheers
> > > >
> > > > Magnus Westerlund
> > > >
> > > >
> > > > -------------------------------------------------------= ---------------
> > > > Networks, Ericsson Research
> > > > -------------------------------------------------------= ---------------
> > > > Ericsson AB=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0| Phone=C2=A0 +46 10 7148287
> > > > Torshamnsgatan 23=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0| Mobile +46 73 0949079
> > > > SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericss= on.com
> > > > -------------------------------------------------------= ---------------
> > > >
> > > >
--
Cheers

Magnus Westerlund


----------------------------------------------------------------------
Networks, Ericsson Research
----------------------------------------------------------------------
Ericsson AB=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| = Phone=C2=A0 +46 10 7148287
Torshamnsgatan 23=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| Mobile +46 73 0= 949079
SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com
----------------------------------------------------------------------


--
Sframe mailing list
Sframe@ietf.org https://www.ietf.org/mailman/listinfo/sframe
--00000000000007618e05ae31647f-- From nobody Mon Aug 31 15:14:30 2020 Return-Path: X-Original-To: sframe@ietfa.amsl.com Delivered-To: sframe@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5EF533A092F for ; Mon, 31 Aug 2020 15:14:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.599 X-Spam-Level: X-Spam-Status: No, score=-17.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.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 vfM5CMjvNMcx for ; Mon, 31 Aug 2020 15:14:25 -0700 (PDT) Received: from mail-vk1-xa2e.google.com (mail-vk1-xa2e.google.com [IPv6:2607:f8b0:4864:20::a2e]) (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 F1BAC3A0123 for ; Mon, 31 Aug 2020 15:14:24 -0700 (PDT) Received: by mail-vk1-xa2e.google.com with SMTP id t189so1665059vka.10 for ; Mon, 31 Aug 2020 15:14:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=29FKiT3Guy44TmMTR5FyPow58HeKb7l/XnyrcQ5plQM=; b=HrGXALltT69zp+6XRX++7UcKJ1Cj/SYd0sa52pckq7BRpIKyHPh/IVXomU+B60cWjT uI+JeyedhY+v3ToBROcmLn5XxNlkkwK6gLZCha9l+vAvF8DftUSr4b7wCGj3Q7nJt7z5 YqaC36uEC8pNxF2DwjJWUESSgg7EPqGhpbGjkx7wE00qmoF/TWTmDHRK/SGon7bCHFvZ YbvwfBuIXyqn5uJWfgLsx1RVR+dPurFr5qPF+X+SpavqBhas868NsIyNqBiti8Vs4o7J CdTa7UBgK6uECUrLTdEgL47qo1JrVU7nvF2XTlIjrsIh+2rHYyd+rLfMuOqmX2LGRuXN 3pcA== 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=29FKiT3Guy44TmMTR5FyPow58HeKb7l/XnyrcQ5plQM=; b=SzdLXSU82WnUNSgCgX/jCDHxL6MCGRYj4fSc03y3emzuddkGoL7h8BzjwYSqn/KXbM 5QdmJsErxIlTgCrSCmx5mAEMzQpBU9YZm+F/9SwUIBgwWhTjBXcS4HcsTx9aEpwy+X3i Del8NDBKhA4oVdm4/27nmvXckom4i/6zZeDIw2iRDujGEC4OEBwtYw4eyxFbyAmWrKRE IDFRm6QDX8pnu+wN6cYLIyYvlt/VPUrVQa77FP/1HJk7rnn6U8+AatUkaAidgAez4bpK P07RIagrB587gNNzBlJJPC5WAZSEZXaClD9DSByOlyxQXiGbqpGJjBUWsajXyHH3hPkb M5hg== X-Gm-Message-State: AOAM530p0fEKQfYurIvv5lH7HoRF4pMw0fz1KftBgx/yW7gzRYvftRRE ifBYNpakDp9ozVN67YKK33KOi9GapHHKyDsEdPPp X-Google-Smtp-Source: ABdhPJxZfxNUzfW27NUix8mD1O92dBXlpd0xXgkaZRtAR0URBps6Irk0rtSMrwlCopRlGVy4MCm+bocuzOxDNJn5dDs= X-Received: by 2002:a1f:286:: with SMTP id 128mr3102129vkc.96.1598912063660; Mon, 31 Aug 2020 15:14:23 -0700 (PDT) MIME-Version: 1.0 References: <69181ed1-d72a-99de-8b4d-9e10276ced91@gmail.com> <771e108a9f25c1bec04d5fcdad58eb55bbb1533d.camel@ericsson.com> In-Reply-To: From: Emad Omara Date: Mon, 31 Aug 2020 15:14:11 -0700 Message-ID: To: Bernard Aboba Cc: Richard Barnes , Magnus Westerlund , "ben@nostrum.com" , "dispatch@ietf.org" , "sframe@ietf.org" , "sergio.garcia.murillo@gmail.com" , "Alex.GOUAILLARD@cosmosoftware.io" Content-Type: multipart/alternative; boundary="00000000000095450005ae33b9b2" Archived-At: Subject: Re: [Sframe] [dispatch] SFRame Next Steps (was SFrame proposed WG charter) X-BeenThere: sframe@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Aug 2020 22:14:28 -0000 --00000000000095450005ae33b9b2 Content-Type: text/plain; charset="UTF-8" Thanks Bernard. The SFrame draft intentionally avoided any RTP dependencies, but as referenced a generic frame marking extension could be used to pass the media metadata in plaintext (but authenticated). Of course the RTP header ext should be HBH encrypted. Regarding packetization, yes a generic RTP packetizer will be used since the media will be encrypted. The frame marking ext will be used to define the frame boundaries. That being said, we need a 2nd draft for SFrame-RTP integration to cover this topic and potentially other topics as well, which I promised I will work on sometime soon :-) On Mon, Aug 31, 2020 at 12:27 PM Bernard Aboba wrote: > Richard said: > > "in the most obvious SFrame+SRTP case, there's a division of labor between > the two protocols, " > > [BA] There is also an interaction between E2E encryption and packetization > that needs to be captured somewhere. In SFrame, the packetization model is > potentially different from PERC, because the SFrame packetizer may not have > visibility into the E2E encrypted payload (e.g. the packetizer may not have > access to the cleartext payload). The implication is that the information > needed to packetize the E2E encrypted frame (e.g. the metadata) needs to be > provided to the packetizer. This info must be sufficient to fill in the > RTP header fields as well as RTP header extensions, including those RTP > header extensions used by an SFU for forwarding (e.g. frame-marking or > Dependency Descriptor). > > I'd note that the current SFrame draft does not address this yet, except > for a figure including a "payload header" in section 1. It is my > understanding that the "Payload Header" represents info provided in the > clear (such as the VP8 header), which is needed by the packetizer. > Implementations that have encrypted this field or have not provided what > was expected (e.g. attempts to utilize the H.264/AVC codec) have > encountered E2E encryption failures. > > One approach to addressing this is to define a "generic packetizer" for a > transport that will be able to packetize and depacketize the E2E encrypted > frame in any codec. If that work is indeed needed, then it should be > described somewhere. > > On Mon, Aug 31, 2020 at 8:41 AM Richard Barnes wrote: > >> Hi Magnus, >> >> I think the intent here is to have a mechanism that provides a subset of >> the security properties required for a given scenario, but which can be >> augmented with additional mechanisms to provide the rest. For example, >> even in the most obvious SFrame+SRTP case, there's a division of labor >> between the two protocols, where SFrame only protects content, and SRTP >> also protects the RTP header and guards against reply by network attackers. >> >> So in a sense it is an intersection (in that it does something that is >> needed by all the use cases), but it might need other things to provide all >> the properties you need in a given scenario. >> >> --Richard >> >> On Mon, Aug 31, 2020 at 10:06 AM Magnus Westerlund < >> magnus.westerlund@ericsson.com> wrote: >> >>> Hi, >>> >>> Thanks for working on addressing my comments when on vacation. >>> >>> I think you mostly arravied at a good place. However, I would like to >>> make one >>> remark about the added language. >>> >>> When it comes to threat models it can't be the intersection of threats >>> across >>> those that occur in the intended usages, it needs to be the union of >>> threats. >>> The formulation added implies intersection to me. >>> >>> Cheers >>> >>> Magnus >>> >>> On Wed, 2020-08-12 at 11:11 -0400, Richard Barnes wrote: >>> > Hey all, >>> > >>> > I agree that all of this stuff is valuable to capture somewhere. In >>> the >>> > interest of keeping the charter fairly succinct, I've added the >>> following: >>> > >>> > """ >>> > The SFrame specification will detail the specific security properties >>> that the >>> > encapsulation provides, and discuss their implications under common >>> usage >>> > scenarios / threat models. >>> > """ >>> > >>> > With that, I think that all the comments we've gotten so far have been >>> > addressed. >>> > >>> > --Richard >>> > >>> > >>> > On Fri, Aug 7, 2020 at 11:51 PM Alexandre GOUAILLARD < >>> > Alex.GOUAILLARD@cosmosoftware.io> wrote: >>> > > guys, >>> > > >>> > > sorry for jumping in so late, quarantine here is very strict. >>> > > >>> > > We had long discussions about this specific point ahead of the draft >>> > > submission. >>> > > We had reached the following consensus: >>> > > - there are multiple usage of media over the internet, e.g. >>> conferencing and >>> > > streaming/broadcast >>> > > - they have very different threat/trust models, with different >>> solutions >>> > > implemented today (transport layer E / E2EE / DRM / Encrypted Media >>> > > Extentions / ...) >>> > > - they all can benefit from SFrame >>> > > >>> > > PERC was, by design, limited to RTP and to Conferencing. Many other >>> use case >>> > > coul benefit from Enhanced Privacy. >>> > > >>> > > We concluded that it would be better to keep SFrame (the media >>> encryption >>> > > part, equivalent to PERC double conceptually), and to have separated >>> > > documents that describe the threat models and the corresponding key >>> > > exchange, signaling and system level decision for each use case. >>> Emad had >>> > > taken an action item for example to make two additional documents to >>> > > describe the Video Conferencing use case, and how SFrame could be >>> used in >>> > > conjunction with MLS to address that specific use case. Someone else >>> could >>> > > take the different use case of the Browsers (which have a specific >>> trust >>> > > model) and make a document showing how SFrame con work with >>> Insertable Frame >>> > > API (and likely some more) to address that use case. CoSMo is >>> interested in >>> > > doing the same thing for Real-Time streaming/Broadcasting. >>> > > >>> > > I think it is a more reasonable approach as, even spending a lot of >>> time >>> > > brainstorming with everyone around the tabel including bernard, we >>> couldn't >>> > > think about one solution to fit all the different "media over >>> internet"'s >>> > > threat model. In my mind, each case should first have an informal >>> document >>> > > to define scope and threat model, and subsequent document to define >>> the >>> > > corresponding specifications. >>> > > - Secure Conferencing Threat model (emad and co.) >>> > > - Secure Conferencing Signalling using MLS (emad and co.) >>> > > - Secure Conferencing using MLS In the browser (contributed by w3c >>> people) >>> > > >>> > > Magnus, what do you think? >>> > > >>> > > Regards, >>> > > >>> > > Dr. ALex. >>> > > >>> > > >>> > > >>> > > On Fri, Aug 7, 2020 at 2:02 AM Emad Omara < >>> > > emadomara=40google.com@dmarc.ietf.org> wrote: >>> > > > Thanks Magnus. I like the idea to explicitly call out the threat >>> model, I >>> > > > think it will be good foundations that control all future design >>> > > > decisions, however I'm not sure if the charter is the right place >>> to call >>> > > > this out. I'd recommend having a separate document that describes >>> the >>> > > > system architecture, goals and threat model. What do you think? >>> > > > >>> > > > Emad >>> > > > >>> > > > On Thu, Aug 6, 2020 at 1:56 AM Magnus Westerlund < >>> > > > magnus.westerlund@ericsson.com> wrote: >>> > > > > Hi, >>> > > > > >>> > > > > On Wed, 2020-08-05 at 22:15 +0200, Sergio Garcia Murillo wrote: >>> > > > > > But shouldn't the "delayed media" attack still be transport >>> agnostic? >>> > > > > I >>> > > > > > mean, this can happen on QUIC and WebRTC SFUs. >>> > > > > >>> > > > > Sorry if I gave the impression that it is not transport >>> agnostic. It is >>> > > > > use case >>> > > > > dependent, any use case that isn't point to point, where there >>> is more >>> > > > > than one >>> > > > > entity that can intentionally remove SFRAME creating gaps in the >>> SFRAME >>> > > > > sequence. In a point to point scenario one can correlate >>> transport >>> > > > > losses with >>> > > > > SFRAME gaps to know give a reasonably strong mitigation against >>> any >>> > > > > third party >>> > > > > removing SFRAMEs or delaying them. That is much harder in a >>> centralized >>> > > > > conference with one or more SFU. >>> > > > > >>> > > > > > >>> > > > > > Anyway, I agree that while SFrame is transport agnostic, the >>> chapter >>> > > > > > should not ignore the interactions with webrtc/quic and we must >>> > > > > ensure >>> > > > > > that we provide a complete working solution regardless of the >>> > > > > transport. >>> > > > > > If we identify that any further working items are required for >>> a >>> > > > > > particular transport, we should at liaise with the appropriate >>> > > > > working >>> > > > > > group for providing a solution. >>> > > > > >>> > > > > My main point is that SFRAME actually needs to discuss the >>> threat model >>> > > > > for the >>> > > > > use cases it intendes to solve. And the mitigation can >>> potentially >>> > > > > include >>> > > > > functionality on the transport level. But the risks to media >>> security in >>> > > > > centralized conferencing needs to be discussed. And centralized >>> > > > > conferencing >>> > > > > will still have the semi-trusted SFUs and all the rest of the >>> third >>> > > > > parties in >>> > > > > addition to the end-points. >>> > > > > >>> > > > > Also what properties one have around end-points invited into the >>> > > > > conference has >>> > > > > a number of question around security properties that needs to be >>> > > > > discussed and >>> > > > > documented. Some examples that I know are relevant: >>> > > > > >>> > > > > - Source authentication: SRTP unless one use TESLA (which isn't >>> really >>> > > > > used) >>> > > > > does only provided the property: Someone that has the key sent >>> this. One >>> > > > > don't >>> > > > > know that it comes from a particular endpoint. >>> > > > > >>> > > > > - Confidentiality when group membership changes: So will SFRAME >>> keying >>> > > > > support a >>> > > > > use case where only the current set of members in a conference >>> can >>> > > > > decrypt the >>> > > > > media and one rekey the media session key for each time the >>> membership >>> > > > > changes? >>> > > > > PERC do support this, will SFRAME? >>> > > > > >>> > > > > There are likely more questions that needs discussion. The PERC >>> > > > > discussion is a >>> > > > > good starting point, but I think when going transport agnostic >>> some of >>> > > > > the >>> > > > > issues needs to be more clearly discussed as the RTP transport >>> can have >>> > > > > affected >>> > > > > how it was discussed, and what reliance on existing mechanism. >>> Which for >>> > > > > SFRAME >>> > > > > likely require a general discussion and then requirements on the >>> > > > > transport and >>> > > > > invovled endpoints and SFU to accomplish mitigations. And thus >>> also what >>> > > > > the >>> > > > > risks are of having no mitigation in place. >>> > > > > >>> > > > > I would really propose that SFRAME is chartered with publishing a >>> > > > > security >>> > > > > consideration and threat model document that is seperate from the >>> > > > > solution to >>> > > > > give this topic full focus. The solution will of necessity need >>> to >>> > > > > reference >>> > > > > that and document what migitagtions that exists in the SFRAME >>> layer and >>> > > > > what >>> > > > > becomes requirements on the transport. >>> > > > > >>> > > > > Cheers >>> > > > > >>> > > > > Magnus Westerlund >>> > > > > >>> > > > > >>> > > > > >>> ---------------------------------------------------------------------- >>> > > > > Networks, Ericsson Research >>> > > > > >>> ---------------------------------------------------------------------- >>> > > > > Ericsson AB | Phone +46 10 7148287 >>> <+46%2010%20714%2082%2087> >>> > > > > Torshamnsgatan 23 | Mobile +46 73 0949079 >>> <+46%2073%20094%2090%2079> >>> > > > > SE-164 80 Stockholm, Sweden | mailto: >>> magnus.westerlund@ericsson.com >>> > > > > >>> ---------------------------------------------------------------------- >>> > > > > >>> > > > > >>> -- >>> Cheers >>> >>> Magnus Westerlund >>> >>> >>> ---------------------------------------------------------------------- >>> Networks, Ericsson Research >>> ---------------------------------------------------------------------- >>> Ericsson AB | Phone +46 10 7148287 >>> <+46%2010%20714%2082%2087> >>> Torshamnsgatan 23 | Mobile +46 73 0949079 >>> <+46%2073%20094%2090%2079> >>> SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com >>> ---------------------------------------------------------------------- >>> >>> >>> -- >> Sframe mailing list >> Sframe@ietf.org >> https://www.ietf.org/mailman/listinfo/sframe >> > --00000000000095450005ae33b9b2 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thanks=C2=A0Bernard. The SFrame draft intentionally avoide= d any RTP dependencies, but as referenced a generic frame marking extension= could be used to pass the media metadata in plaintext (but authenticated).= Of course the RTP header ext should be HBH encrypted.=C2=A0 Regarding pack= etization, yes a generic RTP packetizer will be used since the media will b= e encrypted. The frame=C2=A0marking ext will be used to define the frame bo= undaries.=C2=A0

That being said, we need a 2nd draft for= SFrame-RTP integration to cover this topic and potentially other=C2=A0topi= cs as well, which I promised I will work on sometime soon :-)=C2=A0

On= Mon, Aug 31, 2020 at 12:27 PM Bernard Aboba <bernard.aboba@gmail.com> wrote:
R= ichard said:=C2=A0

"in the most obvious SFrame+SRTP= case, there's a division of labor between the two protocols,=C2=A0&quo= t;

[BA] There is also an interaction between E2E e= ncryption and packetization that needs to be captured somewhere. In SFrame,= the packetization model is potentially different from PERC, because the SF= rame packetizer may not have visibility into the E2E encrypted payload (e.g= . the packetizer may not have access to the cleartext payload).=C2=A0 The i= mplication is that the information needed to packetize the E2E encrypted fr= ame (e.g. the metadata) needs to be provided to the packetizer.=C2=A0 This = info must be sufficient to fill in the RTP header fields as well as RTP hea= der extensions, including those RTP header extensions used by an SFU for fo= rwarding (e.g. frame-marking or Dependency Descriptor).=C2=A0=C2=A0

I'd note that the current SFrame draft does not addre= ss this yet, except for a figure including a "payload header" in = section 1.=C2=A0 It is my understanding that the "Payload Header"= represents info provided in the clear (such as the VP8 header), which is n= eeded by the packetizer.=C2=A0 Implementations that have encrypted this fie= ld or have not provided what was expected (e.g. attempts to utilize the H.2= 64/AVC codec) have encountered E2E encryption failures.=C2=A0
One approach to addressing this is to define a "generic pa= cketizer" for a transport that will be able to packetize and depacketi= ze the E2E encrypted frame in any codec.=C2=A0 If that work is indeed neede= d, then it should be described somewhere.=C2=A0

On Mon, Aug 31, = 2020 at 8:41 AM Richard Barnes <rlb@ipv.sx> wrote:
Hi Magnus,

I think the intent here is to have a mechanism that provides a subset of t= he security properties required for a given scenario, but which can be augm= ented with additional mechanisms to provide the rest.=C2=A0 For example, ev= en in the most obvious SFrame+SRTP case, there's a division of labor be= tween the two protocols, where SFrame only protects content, and SRTP also = protects the RTP header and guards against reply by network attackers.

So in a sense it is an intersection (in that it does s= omething that is needed by all the use cases), but it might need other thin= gs to provide all the properties you need in a given scenario.
--Richard

On Mon, Aug 31, 2020 at 10:06 AM Magnus Westerlun= d <m= agnus.westerlund@ericsson.com> wrote:
Hi,

Thanks for working on addressing my comments when on vacation.

I think you mostly arravied at a good place. However, I would like to make = one
remark about the added language.

When it comes to threat models it can't be the intersection of threats = across
those that occur in the intended usages, it needs to be the union of threat= s.
The formulation added implies intersection to me.

Cheers

Magnus

On Wed, 2020-08-12 at 11:11 -0400, Richard Barnes wrote:
> Hey all,
>
> I agree that all of this stuff is valuable to capture somewhere.=C2=A0= In the
> interest of keeping the charter fairly succinct, I've added the fo= llowing:
>
> """
> The SFrame specification will detail the specific security properties = that the
> encapsulation provides, and discuss their implications under common us= age
> scenarios / threat models.
> """
>
> With that, I think that all the comments we've gotten so far have = been
> addressed.
>
> --Richard
>
>
> On Fri, Aug 7, 2020 at 11:51 PM Alexandre GOUAILLARD <
> = Alex.GOUAILLARD@cosmosoftware.io> wrote:
> > guys,
> >
> > sorry for jumping in so late, quarantine here is very strict.
> >
> > We had long discussions about this specific point ahead of the dr= aft
> > submission.
> > We had reached the following consensus:
> > - there are multiple usage of media over the internet, e.g. confe= rencing and
> > streaming/broadcast
> > - they have very different threat/trust models, with different so= lutions
> > implemented today (transport layer E / E2EE / DRM / Encrypted Med= ia
> > Extentions / ...)
> > - they all can benefit from SFrame
> >
> > PERC was, by design, limited to RTP and to Conferencing. Many oth= er use case
> > coul benefit from Enhanced Privacy.
> >
> > We concluded that it would be better to keep SFrame (the media en= cryption
> > part, equivalent to PERC double conceptually), and to have separa= ted
> > documents that describe the threat models and the corresponding k= ey
> > exchange, signaling and system level decision for each use case. = Emad had
> > taken an action item for example to make two additional documents= to
> > describe the Video Conferencing use case, and how SFrame could be= used in
> > conjunction with MLS to address that specific use case. Someone e= lse could
> > take the different use case of the Browsers (which have a specifi= c trust
> > model) and make a document showing how SFrame con work with Inser= table Frame
> > API (and likely some more) to address that use case. CoSMo is int= erested in
> > doing the same thing for Real-Time streaming/Broadcasting.
> >
> > I think it is a more reasonable approach as, even spending a lot = of time
> > brainstorming with everyone around the tabel including bernard, w= e couldn't
> > think about one solution to fit all the different "media ove= r internet"'s
> > threat model. In my mind, each case should first have an informal= document
> > to define scope and threat model, and subsequent document to defi= ne the
> > corresponding specifications.
> > - Secure Conferencing Threat model (emad and co.)
> > - Secure Conferencing Signalling using MLS (emad and co.)
> > - Secure Conferencing using MLS In the browser (contributed by w3= c people)
> >
> > Magnus, what do you think?
> >
> > Regards,
> >
> > Dr. ALex.
> >
> >
> >
> > On Fri, Aug 7, 2020 at 2:02 AM Emad Omara <
> > emadomara=3D40google.com@dmarc.ietf.org> wrote:
> > > Thanks Magnus. I like the idea to explicitly call out the th= reat model, I
> > > think it will be good foundations that control all future de= sign
> > > decisions, however I'm not sure if the charter is the ri= ght place to call
> > > this out. I'd recommend having a separate document that = describes the
> > > system architecture, goals and threat model. What do you thi= nk?
> > >
> > > Emad
> > >
> > > On Thu, Aug 6, 2020 at 1:56 AM Magnus Westerlund <
> > > magnus.westerlund@ericsson.com> wrote:
> > > > Hi,
> > > >
> > > > On Wed, 2020-08-05 at 22:15 +0200, Sergio Garcia Murill= o wrote:
> > > > > But shouldn't the "delayed media" at= tack still be transport agnostic?
> > > > I
> > > > > mean, this can happen on QUIC and WebRTC SFUs.
> > > >
> > > > Sorry if I gave the impression that it is not transport= agnostic. It is
> > > > use case
> > > > dependent, any use case that isn't point to point, = where there is more
> > > > than one
> > > > entity that can intentionally remove SFRAME creating ga= ps in the SFRAME
> > > > sequence. In a point to point scenario one can correlat= e transport
> > > > losses with
> > > > SFRAME gaps to know give a reasonably strong mitigation= against any
> > > > third party
> > > > removing SFRAMEs or delaying them. That is much harder = in a centralized
> > > > conference with one or more SFU.
> > > >
> > > > >
> > > > > Anyway, I agree that while SFrame is transport agn= ostic, the chapter
> > > > > should not ignore the interactions with webrtc/qui= c and we must
> > > > ensure
> > > > > that we provide a complete working solution regard= less of the
> > > > transport.
> > > > > If we identify that any further working items are = required for a
> > > > > particular transport, we should at liaise with the= appropriate
> > > > working
> > > > > group for providing a solution.
> > > >
> > > > My main point is that SFRAME actually needs to discuss = the threat model
> > > > for the
> > > > use cases it intendes to solve. And the mitigation can = potentially
> > > > include
> > > > functionality on the transport level. But the risks to = media security in
> > > > centralized conferencing needs to be discussed. And cen= tralized
> > > > conferencing
> > > > will still have the semi-trusted SFUs and all the rest = of the third
> > > > parties in
> > > > addition to the end-points.
> > > >
> > > > Also what properties one have around end-points invited= into the
> > > > conference has
> > > > a number of question around security properties that ne= eds to be
> > > > discussed and
> > > > documented. Some examples that I know are relevant:
> > > >
> > > > - Source authentication: SRTP unless one use TESLA (whi= ch isn't really
> > > > used)
> > > > does only provided the property: Someone that has the k= ey sent this. One
> > > > don't
> > > > know that it comes from a particular endpoint.
> > > >
> > > > - Confidentiality when group membership changes: So wil= l SFRAME keying
> > > > support a
> > > > use case where only the current set of members in a con= ference can
> > > > decrypt the
> > > > media and one rekey the media session key for each time= the membership
> > > > changes?
> > > > PERC do support this, will SFRAME?
> > > >
> > > > There are likely more questions that needs discussion. = The PERC
> > > > discussion is a
> > > > good starting point, but I think when going transport a= gnostic some of
> > > > the
> > > > issues needs to be more clearly discussed as the RTP tr= ansport can have
> > > > affected
> > > > how it was discussed, and what reliance on existing mec= hanism. Which for
> > > > SFRAME
> > > > likely require a general discussion and then requiremen= ts on the
> > > > transport and
> > > > invovled endpoints and SFU to accomplish mitigations. A= nd thus also what
> > > > the
> > > > risks are of having no mitigation in place.
> > > >
> > > > I would really propose that SFRAME is chartered with pu= blishing a
> > > > security
> > > > consideration and threat model document that is seperat= e from the
> > > > solution to
> > > > give this topic full focus. The solution will of necess= ity need to
> > > > reference
> > > > that and document what migitagtions that exists in the = SFRAME layer and
> > > > what
> > > > becomes requirements on the transport.
> > > >
> > > > Cheers
> > > >
> > > > Magnus Westerlund
> > > >
> > > >
> > > > -------------------------------------------------------= ---------------
> > > > Networks, Ericsson Research
> > > > -------------------------------------------------------= ---------------
> > > > Ericsson AB=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0| Phone=C2=A0 +46 10 7148287
> > > > Torshamnsgatan 23=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0| Mobile +46 73 0949079
> > > > SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericss= on.com
> > > > -------------------------------------------------------= ---------------
> > > >
> > > >
--
Cheers

Magnus Westerlund


----------------------------------------------------------------------
Networks, Ericsson Research
----------------------------------------------------------------------
Ericsson AB=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| = Phone=C2=A0 +46 10 7148287
Torshamnsgatan 23=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| Mobile = +46 73 0949079
SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com
----------------------------------------------------------------------


--
Sframe mailing list
Sframe@ietf.org https://www.ietf.org/mailman/listinfo/sframe
--00000000000095450005ae33b9b2--