From nobody Tue Jun 2 11:32: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 7E9CA3A0C8B for ; Tue, 2 Jun 2020 11:32:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.6 X-Spam-Level: X-Spam-Status: No, score=-17.6 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, 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 II0i_Ozes58K for ; Tue, 2 Jun 2020 11:32:25 -0700 (PDT) Received: from mail-ej1-x62a.google.com (mail-ej1-x62a.google.com [IPv6:2a00:1450:4864:20::62a]) (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 3CF7D3A0EA0 for ; Tue, 2 Jun 2020 11:32:14 -0700 (PDT) Received: by mail-ej1-x62a.google.com with SMTP id l27so13793509ejc.1 for ; Tue, 02 Jun 2020 11:32:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=zMHu9zTjP/uixmOeQN93xP8STcV1/tutsXAhqECt/6k=; b=bD81PnBVVkU35PZXeVeOjD+ebCYy/iMFXlY430+Nr9ZfdMLNtosmvTfQe1+sbB7aJc AWQ6yAzFsHeeOpaCywJ6T79RqNPYAnkqBnqvpHy6y2H/w8iv5cLE5lyQZ1FlUm4e0wuH BLwJcQoXNimuYBWe+VB4Y846YHpwf/pwdsJ7s97WSTqA2myuT9ZNEGRgAbMnJbf++CXz wWP7F5qshrLkrsNQBiXnQo/oU+qJNTlHdZ0v314C6pnmWJ4ar+QJHJMKGuABdzMofkeI WpTr2o4vAYPDIv2YWL6ljo+H+pAHLyPJUb2GjJwjfX2n7nROWIOuKixBP64srPj2zNxb CSDg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=zMHu9zTjP/uixmOeQN93xP8STcV1/tutsXAhqECt/6k=; b=K27Zki+UP1KAyyQUoFc3X3LjKPGtw+yx5kZW6l8B+BebaC176+qIVd8JL0jh+Qhpm6 migRFFYd+llhGDUQhOv0LQAwFYjWbDKQRMhPm+Evhw1yKR3PG+7Ka5adsD9xehPQvJ26 ziwtqOt8nh3dOzRclwqH4t0ZhPFCaRUzTEdCoUe10wye1b3oPpmNrEiIFtv8njWQyu9y znO3Tdd4PpY6nSW00FiOoy4V90cNm9z1vSGPjq2yWRtToTp40S05EbMfGXyvZzbtUvk6 1mdKj3HkSQBG++ge4CE1JuoRqTVZWbyw9gQBfYgFNk12HoNNxHPGEPCvoI4qiH/Y1ypq fWRw== X-Gm-Message-State: AOAM531ojUT0Ym5GLxVShukSRDM49gL7szMvlQCQXI17J51Z3zCUZPId AqQiFu6sVzyhHbj2vyyB775w34sRgqWXs/GVfldHxhMAZA== X-Google-Smtp-Source: ABdhPJyGzF5ohweFfxZ4ErVvirQinJultDTHGF0rqTjI1qe6PrCaBGlMEfS62dFdy6QaQSgztgf8ZT+lFxuvTKsr2jk= X-Received: by 2002:a17:906:22d0:: with SMTP id q16mr6789499eja.455.1591122728931; Tue, 02 Jun 2020 11:32:08 -0700 (PDT) MIME-Version: 1.0 From: Emad Omara Date: Tue, 2 Jun 2020 11:31:57 -0700 Message-ID: To: Sframe@ietf.org Content-Type: multipart/alternative; boundary="0000000000000dcfa105a71e21bb" Archived-At: Subject: [Sframe] Github repo for SFrame documents 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: Tue, 02 Jun 2020 18:32:27 -0000 --0000000000000dcfa105a71e21bb Content-Type: text/plain; charset="UTF-8" Hi all, The Github repo is now available for the document, please feel free to file issues directly or send PR if you have other improvements and suggestions. https://github.com/eomara/sframe Thanks Emad --0000000000000dcfa105a71e21bb Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi all,

The Github repo is now availabl= e for the document, please feel free to file issues directly or send PR if = you have other improvements and suggestions.


--0000000000000dcfa105a71e21bb-- From nobody Fri Jun 12 01:03:24 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 7CDEF3A0CF2 for ; Fri, 12 Jun 2020 01:03:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.597 X-Spam-Level: X-Spam-Status: No, score=-9.597 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, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=LZXvIpnz; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=ZCCBcUqy 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 SH1idg-PCYrf for ; Fri, 12 Jun 2020 01:03:20 -0700 (PDT) Received: from alln-iport-6.cisco.com (alln-iport-6.cisco.com [173.37.142.93]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6C0C83A0CF0 for ; Fri, 12 Jun 2020 01:03:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6402; q=dns/txt; s=iport; t=1591949000; x=1593158600; h=from:to:cc:subject:date:message-id:mime-version; bh=59D4B+PN8uZGnRFdRdXUF7Ei78/Y9SLVB9G7FvF6YA0=; b=LZXvIpnzAxHTki3aE033dlNQAVlBQjwHDcBgMWljXXF7YUrI21el+ONr a1dhaGt1TbCN4N522cO+wCsRmy7TvLabbr39TyOVEigrtTZ2B8Hi0G2Kp IFDGPEHKvlszDAe776ZS96JswARH0Ksu9fbF0uV9XbQEIGrFr+Sy1YL9c Y=; IronPort-PHdr: =?us-ascii?q?9a23=3ALBmqHR8txJkpp/9uRHGN82YQeigqvan1NQcJ65?= =?us-ascii?q?0hzqhDabmn44+7ZRaN5PhxghnOR4qIo/5Hiu+DtafmVCRA5Juaq3kNfdRKUA?= =?us-ascii?q?NNksQZmQEsQavnQU32JfLndWo2ScJFUlI2/nynPw5SAsmtL1HXq2e5uDgVHB?= =?us-ascii?q?i3PAFpJ+PzT4jVicn/1+2795DJJQtSgz/oarJpJxLwpgLU5cQ=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DtCQAUNuNe/5FdJa1mgQmCbS9SB29?= =?us-ascii?q?YLywKh2ADoSaEaIJSA1ULAQEBDAEBLQIEAQGERAKCJAIkOBMCAwEBCwEBBQE?= =?us-ascii?q?BAQIBBgRthVsBC4V1FhsTAQE3AREBgQAfBwEEDg0agwWBfk0DLgGoNAKBOYh?= =?us-ascii?q?hdIE0gwEBAQWFMxiCDgmBOIJkiUodGoFBP4FUh1uDRYItmFqaZYECCoJZmTu?= =?us-ascii?q?eZ5EWni0CBAIEBQIOAQEFgWoiKYEtcBWDJFAXAg2SD4pWdDcCBggBAQMJfI4?= =?us-ascii?q?hAYEQAQE?= X-IronPort-AV: E=Sophos;i="5.73,502,1583193600"; d="scan'208,217";a="523674677" Received: from rcdn-core-9.cisco.com ([173.37.93.145]) by alln-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 12 Jun 2020 08:03:17 +0000 Received: from XCH-ALN-002.cisco.com (xch-aln-002.cisco.com [173.36.7.12]) by rcdn-core-9.cisco.com (8.15.2/8.15.2) with ESMTPS id 05C83HFh001646 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL) for ; Fri, 12 Jun 2020 08:03:17 GMT Received: from xhs-aln-001.cisco.com (173.37.135.118) by XCH-ALN-002.cisco.com (173.36.7.12) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Fri, 12 Jun 2020 03:03:17 -0500 Received: from xhs-rcd-002.cisco.com (173.37.227.247) by xhs-aln-001.cisco.com (173.37.135.118) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Fri, 12 Jun 2020 03:03:16 -0500 Received: from NAM10-MW2-obe.outbound.protection.outlook.com (72.163.14.9) by xhs-rcd-002.cisco.com (173.37.227.247) with Microsoft SMTP Server (TLS) id 15.0.1497.2 via Frontend Transport; Fri, 12 Jun 2020 03:03:16 -0500 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=HEm9NdCMoEUP+zgZeEGsDO1oHV5uvB0ZVoyiDB+ElYbzQd3A9pg6BBcXhD5ZnP7oOzZYwmWqYb4YTYuugeK+1nmgDCdRp79TLGmMSqIT5UGwrqA8AELP21P5bypNTmZYKyR5+dMw4MHb4hiUmzIUh0hpnk4PxxjmMjfZ3E5aKXnHdck0yTnZX5BtQdCiokbWpNEEtoq5uP46I1RjAu3R9jZ5TBLtlJPf6kjkgMYK43b0yVyIhl+Ss/tfPK0UEj8KkO6h0oyhI7UczzSCzOrGgu4f07gpdF+3Wd2IoI00u/ZYqPq6LMB+erUymyppSaFZ5Q0DmVlHyEW8iNGey4lgXg== 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=V+NAOSMt4MzfmFGGZK2P4g3/cntbNcUGjK5bgI5JFBM=; b=he3czeUmNjeSrGFbIgMLKtCtb97ZbpJFs8T2c878ES/dq/2Wo7ILb9WYQ/k+JhOyQZ9J2sz3uhwD1t2IOXExpw1pcAtYn2iDi0vPSFrNyWA+y1VcsyhhJ6iuI2vzHrNQNNG4S/O7HzJyGxrsYx4tyn7lyQobzpJwxkXt8LbIGgEJyiRk/eA79VASri7/yk+qD/Tevy6fo8h7FxhVlBE2E3oandtr6FeO3lWYeRUEmDxBzHH5EJf5evwPgqh6WMi+9CFWkbqK97v3DItEB/HWMj23UkweTzzdd9Gba8e4ieyqwBWLcXSEpZGNHaZBbOXdhGrmRcPbTDo06LM/o2t1EQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=V+NAOSMt4MzfmFGGZK2P4g3/cntbNcUGjK5bgI5JFBM=; b=ZCCBcUqyIF3vXiwA/GoKVtb8DifL40HTQd+4X++fMJ3svfCaeHSsHjSDag/dxg/XPyWEKth+aJQj+5639ryZy3kl1/JoYG+RiMrM6fy4n6mbZ1bDYvviV5MTnz51644K0W3D9azzuMPk3zJf7cCS7tDTUBTuFO3ajMlP7/MluEA= Received: from DM5PR11MB0026.namprd11.prod.outlook.com (2603:10b6:4:62::35) by DM6PR11MB3066.namprd11.prod.outlook.com (2603:10b6:5:64::15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3066.18; Fri, 12 Jun 2020 08:03:15 +0000 Received: from DM5PR11MB0026.namprd11.prod.outlook.com ([fe80::349d:7e4f:afe7:6e2f]) by DM5PR11MB0026.namprd11.prod.outlook.com ([fe80::349d:7e4f:afe7:6e2f%5]) with mapi id 15.20.3088.023; Fri, 12 Jun 2020 08:03:15 +0000 From: "Pascal Buhler (pabuhler)" To: "Sframe@ietf.org" CC: "Pascal Buhler (pabuhler)" Thread-Topic: using sframe with existing media networks Thread-Index: AdZAj9FrzPpMXu2GSPmuNnjw5iXyEg== Date: Fri, 12 Jun 2020 08:03:15 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=cisco.com; x-originating-ip: [173.38.220.38] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: c1f0c93b-6b3f-4264-00d4-08d80ea70fb6 x-ms-traffictypediagnostic: DM6PR11MB3066: x-ms-exchange-transport-forked: True x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 0432A04947 x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: wce5RdHf3szl2tHKnqBqaF5L2o1pG1L7NtnMnUyhW5wiDcgos0qOySR4VlIPMGskLpYxKx4FcHA766YlnBqjHLFOMxKLOwWSoMvnTEz1R0Qfgnn0Ue5wmLabXodOv9oyYzNJf5Kp3ugpTGRyzwaJmaED12NMYlVBgFHgp0OKiw5S6UKRVqLV8RULWRcow7D0xGwpIiRVH1cyqmpmGAUQvifYR00qapXQR949kztcfnlraLImW2KHNkds+hOF0pVvfsw5WMksLy+8RT3AxsZJLY9Yyii+Fa8sTU5oTGR3uKQdkTMj1gH3P7IeejE8F9/0hOXOR60K49w/1V5O9OPWmA== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DM5PR11MB0026.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(346002)(376002)(366004)(136003)(39860400002)(396003)(52536014)(8676002)(316002)(8936002)(5660300002)(2906002)(9326002)(478600001)(6916009)(71200400001)(64756008)(107886003)(186003)(66946007)(86362001)(33656002)(76116006)(55016002)(6506007)(4326008)(66556008)(9686003)(66446008)(66476007)(26005)(7696005); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: j1w/Af3tflPfTQsUM4VoRq+vewGSeMPhvHN/Z4wZwZOuc+Q7WD6yc3V9UkKLV7e3S3Mh/94YzgnOu1A8fz3CRayoLNojpk1pVhsWwOEbQcw1drezw0uZFDKM/xPO4Kp2SO6s7Lv9/YhBCLYtbj6MhOdNs0EAtFOtjMngc5/oeuCuUP6rytCNWHYDSDTJxl19PezXM+MXrduJD1gFf/VKVyJO76MIZPGY8ghhtpULEPDAFXAz1d0updJ34X2OuyTmZugiAeZ9z8Q7vtmsGIi7/xxbyf/wHQZ7FqP+PvWT33kNfdZCVyoAuIf/k6xtcil0c5Ke9sX7KcWbNL2K/+sTariDKhUbgTdGMgdGdXch0HGMb/N09QNGd8v3ytC1WFcQC1lUSeryAEzlKXJayivP+DnV0RjE5SmCssFf/zF0ZlsKiUCH+/adtAWp/lYBrRIFZXqzMnp11f3uF7VBlTmQZ/1UewY/ZuRQu7GP9meY3fU= Content-Type: multipart/alternative; boundary="_000_DM5PR11MB0026C9E036B42EC322A77A4DD5810DM5PR11MB0026namp_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: c1f0c93b-6b3f-4264-00d4-08d80ea70fb6 X-MS-Exchange-CrossTenant-originalarrivaltime: 12 Jun 2020 08:03:15.7119 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: iDLo2JZ9OMpwqGqd0jg/RGoffp5H+kBQIIzA04ZuXJJC2CVtfmKQtF3Zba9tHC8DeExx8VrKScfunP9rdGwaow== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR11MB3066 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.36.7.12, xch-aln-002.cisco.com X-Outbound-Node: rcdn-core-9.cisco.com Archived-At: Subject: [Sframe] using sframe with existing media networks 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: Fri, 12 Jun 2020 08:03:23 -0000 --_000_DM5PR11MB0026C9E036B42EC322A77A4DD5810DM5PR11MB0026namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, I had a couple of questions relating to the draft posted by Emad and sframe= usage in general, not sure if it is best to post here, on github or a diff= erent forum. First I make the assumption that although sframe is a valid concept/standar= d on its own and that webrtc is not explicitly mentioned, I take it that it= is in the context of webrtc and the insertable streams api that this was o= riginally developed. I am looking at this from the prospective of a webrtc gateway, so there is = no guarantee that there is a webrtc client at both ends. I see that the encrypted frame will be packetized with a generic RTP packet= izer and use a generic RTP header extension, but no references to what thes= e are or how one would signal/configure a client to use the generic packeti= ze instead of a codec specific one. This is maybe not directly relayed to t= he sframe standard but relevant when using sframe in conjunction with other= standards, for example SDP. Secondly I am interested in the Partial Decoding section, this seams to req= uire that an entire frame is encoded as a single blob but there are many co= decs that can encode parts of a frame as independent units, for example a s= ingle NAL that covers only a slice of a frame in H.264 or a single OBU that= contains a tile in AV1. In these cases the units could still span many pac= kets. Is it possible for sframe to work in these cases if one considers eac= h of these unit to be a frame in the sframe concept? I am not familiar enou= gh with the insertable streams api in webrtc to know how that works in the = case of slices and tiles. Thanks pascal --_000_DM5PR11MB0026C9E036B42EC322A77A4DD5810DM5PR11MB0026namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

I had a couple of questions relating to the draft po= sted by Emad and sframe usage in general, not sure if it is best to post he= re, on github or a different forum.

 

First I make the assumption that although sframe is = a valid concept/standard on its own and that webrtc is not explicitly menti= oned, I take it that it is in the context of webrtc and the insertable stre= ams api that this was originally developed.

 

I am looking at this from the prospective of a webrt= c gateway, so there is no guarantee that there is a webrtc client at both e= nds.

 

I see that the encrypted frame will be packetized wi= th a generic RTP packetizer and use a generic RTP header extension, but no = references to what these are or how one would signal/configure a client to = use the generic packetize instead of a codec specific one. This is maybe not directly relayed to the sframe = standard but relevant when using sframe in conjunction with other standards= , for example SDP.

 

Secondly I am interested in the Partial Decoding section, this seams to require that an entire frame is enc= oded as a single blob but there are many codecs that can encode parts of a = frame as independent units, for example a single NAL that covers only a sli= ce of a frame in H.264 or a single OBU that contains a tile in AV1. In these cases the units could still span= many packets. Is it possible for sframe to work in these cases if one cons= iders each of these unit to be a frame in the sframe concept? I am not fami= liar enough with the insertable streams api in webrtc to know how that works in the case of slices and til= es.

 

Thanks

 

pascal

 

 

--_000_DM5PR11MB0026C9E036B42EC322A77A4DD5810DM5PR11MB0026namp_-- From nobody Fri Jun 12 09:33:09 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 13FB63A089B for ; Fri, 12 Jun 2020 09:33:07 -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 xV8He9SrECg3 for ; Fri, 12 Jun 2020 09:33:05 -0700 (PDT) Received: from mail-vs1-xe34.google.com (mail-vs1-xe34.google.com [IPv6:2607:f8b0:4864:20::e34]) (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 56F403A09F1 for ; Fri, 12 Jun 2020 09:33:05 -0700 (PDT) Received: by mail-vs1-xe34.google.com with SMTP id 190so5621912vsr.9 for ; Fri, 12 Jun 2020 09:33:05 -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=w+yJ4kMUpylHTVIryXlDAYEvG3KCgBwTFoJiaZfs2B4=; b=Tqv1uEwasdRKTbjSqdn8jmEj95S/pkOsMuh5Oj9pLWc1JEGp1az04zDqjUHqlt+6vD 79bsfUQdQGd0x7i8F0rGF3fGYcGipCv6XLsa7U3EBzYOQZBDVmVggQyieN3hRwkEFOG9 XS2wdmVuvc+3ZmeX2sQ4BHezWe5GuqGvoUTcTAkkEbyU6VQ9D0XzoF4CbRmnx5TycIwX Bi26jArk5+J+5mTSmf88DzrM0YCM6ZxYbIQwBGenRwABRYXOCr+giN3ScYugVy4NvD8y Q1XW4TA9uJWligegeklPqSa8WtPVVk1G9aL3E2ApqVO9VXxPkXGGXQcndmUWsoVtoR9r jqrw== 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=w+yJ4kMUpylHTVIryXlDAYEvG3KCgBwTFoJiaZfs2B4=; b=iIzzcyTPaimRhywCX/2g7EAX4EHF4Pk2Cv80MVcGcJq/tfGe3vsZAM1LyqJkLfKrkb 29iwl7LhEeSpyNjsX01bi+y6Hkjw+UtCTMi9TWTlfZOsmuyINOsJq4ASBCE5Gy82aVig lb1hL4RsZmccJf6VCB/csarZd7LwDxe4HYtNy+lv6qt11uRbnGPZ3XXQrXuNb/ThfguH A4WC5FHJV0Vo3jhbuMI88AV544CWG9Dfzn720DLs+48Oh5WSwiaSGxSm9UMiTpNgwWXL EqhzlaHX8EenqZIQgjtnDvwcS29r61+CMUWxF1X70zMFt64jH2Erpl2+e+Q80gttCgzj 6EFQ== X-Gm-Message-State: AOAM533HZO90ru3uWvHzTzHGAx8KsL3Dm1dA/MDej+R4qHZAJdU6kLLw VKTEo8uHHku/814K1o88ovjRuiWIOm8nvc/ScTJ7iQ== X-Google-Smtp-Source: ABdhPJwSB3tpyPD4HLLalDtjw+Jl2NPIX+HFA45HHVi2V6A596qI8KEznN+SBLvLUgwwvxXCsnkHIGzZ6ripaQdL4ec= X-Received: by 2002:a67:fb49:: with SMTP id e9mr11106322vsr.231.1591979583451; Fri, 12 Jun 2020 09:33:03 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Justin Uberti Date: Fri, 12 Jun 2020 09:32:51 -0700 Message-ID: To: "Pascal Buhler (pabuhler)" Cc: "Sframe@ietf.org" , "Pascal Buhler (pabuhler)" Content-Type: multipart/alternative; boundary="000000000000904c3805a7e5a1d1" Archived-At: Subject: Re: [Sframe] using sframe with existing media networks 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: Fri, 12 Jun 2020 16:33:07 -0000 --000000000000904c3805a7e5a1d1 Content-Type: text/plain; charset="UTF-8" On Fri, Jun 12, 2020 at 1:03 AM Pascal Buhler (pabuhler) wrote: > Hi, > > > > I had a couple of questions relating to the draft posted by Emad and > sframe usage in general, not sure if it is best to post here, on github or > a different forum. > > > > First I make the assumption that although sframe is a valid > concept/standard on its own and that webrtc is not explicitly mentioned, I > take it that it is in the context of webrtc and the insertable streams api > that this was originally developed. > > > > I am looking at this from the prospective of a webrtc gateway, so there is > no guarantee that there is a webrtc client at both ends. > > > > I see that the encrypted frame will be packetized with a generic RTP > packetizer and use a generic RTP header extension, but no references to > what these are or how one would signal/configure a client to use the > generic packetize instead of a codec specific one. This is maybe not > directly relayed to the sframe standard but relevant when using sframe in > conjunction with other standards, for example SDP. > Yes, some form of signaling is definitely needed, perhaps some new option in a m= section negotiating the use of a generic packetizer. > > > Secondly I am interested in the Partial Decoding section, this seams to > require that an entire frame is encoded as a single blob but there are many > codecs that can encode parts of a frame as independent units, for example a > single NAL that covers only a slice of a frame in H.264 or a single OBU > that contains a tile in AV1. In these cases the units could still span many > packets. Is it possible for sframe to work in these cases if one considers > each of these unit to be a frame in the sframe concept? I am not familiar > enough with the insertable streams api in webrtc to know how that works in > the case of slices and tiles. > Yes, to enable this each independently decodable unit would be a 'frame' for SFrame. This would include H.264 slices/AV1 OBUs, as well as individual layers in a scalable coding context. --000000000000904c3805a7e5a1d1 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Fri, Jun 12, 2020 at 1:03 AM Pasca= l Buhler (pabuhler) <pabuhler=3D40cisco.com@dmarc.ietf.org> wrote:

Hi,

=C2=A0

I had a couple of questions relating to the draft po= sted by Emad and sframe usage in general, not sure if it is best to post he= re, on github or a different forum.

=C2=A0

First I make the assumption that although sframe is = a valid concept/standard on its own and that webrtc is not explicitly menti= oned, I take it that it is in the context of webrtc and the insertable stre= ams api that this was originally developed.

=C2=A0

I am looking at this from the prospective of a webrt= c gateway, so there is no guarantee that there is a webrtc client at both e= nds.

=C2=A0

I see that the encrypted frame will be packetized wi= th a generic RTP packetizer and use a generic RTP header extension, but no = references to what these are or how one would signal/configure a client to = use the generic packetize instead of a codec specific one. This is maybe not directly relayed to the sframe = standard but relevant when using sframe in conjunction with other standards= , for example SDP.


Yes, som= e form of signaling is definitely needed, perhaps some new option in a m=3D= section negotiating the use of a generic packetizer.=C2=A0

=C2=A0

Secondly I am interested in the Partial Decoding section, this seams to require that an entire frame is enc= oded as a single blob but there are many codecs that can encode parts of a = frame as independent units, for example a single NAL that covers only a sli= ce of a frame in H.264 or a single OBU that contains a tile in AV1. In these cases the units could still span= many packets. Is it possible for sframe to work in these cases if one cons= iders each of these unit to be a frame in the sframe concept? I am not fami= liar enough with the insertable streams api in webrtc to know how that works in the case of slices and til= es.


Yes, to enable t= his each independently decodable unit would be a 'frame' for SFrame= . This would include H.264 slices/AV1 OBUs, as well as individual layers in= a scalable coding context.


--000000000000904c3805a7e5a1d1-- From nobody Mon Jun 15 10:32:49 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 2922E3A060D for ; Mon, 15 Jun 2020 10:32:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.339 X-Spam-Level: X-Spam-Status: No, score=-17.339 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, HTML_OBFUSCATE_05_10=0.26, 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 9k2lGzEcDH3h for ; Mon, 15 Jun 2020 10:32:42 -0700 (PDT) Received: from mail-ej1-x62e.google.com (mail-ej1-x62e.google.com [IPv6:2a00:1450:4864:20::62e]) (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 A2D4C3A060A for ; Mon, 15 Jun 2020 10:32:42 -0700 (PDT) Received: by mail-ej1-x62e.google.com with SMTP id o15so18302590ejm.12 for ; Mon, 15 Jun 2020 10:32:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:from:date:message-id:subject:to:cc; bh=i2AtmdcUHK/08n463ylex7KYoonH7f4mhV8ymlTaFx4=; b=jnL9trnp24dRa/hdf+r4SJ/kin5S9frhG9f0Tz7VdvnEg1v/xRE7upncwaDVlTjepD Gyb9hxSgUTqKyoR8KfwajICgMVFrnwRpl5aHzZqB5jOGNN72tkO4sFS3O0OF3DbAVyqQ j1Cy27nbNqnQAZ+lJqDcYjnjQkzIOCtNBqmZ5zbQF9Cu3cqQBv3BpaWcGs9sCCEFCKmA YseNe2smUMX9w9Vpn6C4Dgm75faW1EGJWlnmcX123q2ixerdGCs0+M0huH+IAHnODTyW 5IrzWQXYLjsC7L5T4AQ3Y5kSBGxjOBll4FhnzNP1IVQ46eartzEkjflM6l7KIZffR/Wg IdoA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to:cc; bh=i2AtmdcUHK/08n463ylex7KYoonH7f4mhV8ymlTaFx4=; b=fZlB/iUmq7lq0aEB3ARqoitXJwdnryS0Dp/Xi2hH9RF+5BJFxD94f8AqAXLPoLZJer SJtz9F895uBgPGJs/8ZkSOYZOR9R3Sq+q6CGVDr8PE1kjb2RRB0zHGiXTjWVT3puUwBq QpEJmD83fUzHoxHX7INIk1ZlurE5weeurTIu49KUCb3UKiTK1tndHCwEntsFfFEBZHuQ +PgLIluEHzPIaBz/QGQPA4FMbEqD9klQKYR/cV+aUJIc4n2knzjpcORT2D6WzKy/iGMb j6Z3BxdxsWzOOcHKnp6Bd7PPWfX+d2znF82V5kIYg8xnh2N8GkjLbgF5yT+SBmixaMpC /JWQ== X-Gm-Message-State: AOAM532MqB3SAxF84/k5XqKAwKoOZHthFPOJ7dxwb/ZHWoUPB9S9ESlY JXIiDZiIPoYVZLrWHU+tTNmI+MCf7r5Auzvt1LZg X-Google-Smtp-Source: ABdhPJyglFS4pgUKAt+tJy5QpIbLfX1DJ7FOlFdHhqVZFz3ElO+WDyRPLJfJqG19u/lHceyREwTwOhNrWSZd5Pk7srk= X-Received: by 2002:a17:906:22d0:: with SMTP id q16mr13852423eja.455.1592242360913; Mon, 15 Jun 2020 10:32:40 -0700 (PDT) MIME-Version: 1.0 From: Emad Omara Date: Mon, 15 Jun 2020 10:32:29 -0700 Message-ID: To: session-request@ietf.org, dispatch@ietf.org Cc: sframe@ietf.org Content-Type: multipart/alternative; boundary="00000000000052047605a822d02e" Archived-At: Subject: [Sframe] Request session at IETF 108 dispatch 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, 15 Jun 2020 17:32:44 -0000 --00000000000052047605a822d02e Content-Type: text/plain; charset="UTF-8" Hi, We would like to have a session in the next IETF to discuss the SFrame draft Can you please help scheduling this? Thanks Emad --00000000000052047605a822d02e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi,

We would like to have a session in = the next IETF to discuss the SFrame draft=C2=A0Can you please help scheduling this?<= /div>

Thanks
Emad
--00000000000052047605a822d02e-- From nobody Mon Jun 15 11:02:52 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 14BE93A0827; Mon, 15 Jun 2020 11:02:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.401 X-Spam-Level: X-Spam-Status: No, score=-1.401 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, HTML_MESSAGE=0.001, KHOP_HELO_FCRDNS=0.276, MAY_BE_FORGED=0.001, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=nostrum.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 i-7T_MzaRug2; Mon, 15 Jun 2020 11:02:46 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (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 BFDE83A0837; Mon, 15 Jun 2020 11:02:46 -0700 (PDT) Received: from bens-macbook.lan (mta-70-120-123-175.stx.rr.com [70.120.123.175] (may be forged)) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id 05FI2c4K074313 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Mon, 15 Jun 2020 13:02:39 -0500 (CDT) (envelope-from ben@nostrum.com) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nostrum.com; s=default; t=1592244160; bh=Drx7FVDaN7vYeoxyaG0Q+rW/xy17m5NzYU/IjE1tO8w=; h=From:Subject:Date:In-Reply-To:Cc:To:References; b=dneW+LfMuKUu9QnbDSkyj3vfGz7UFOWGhMugd/pVXLEM6owzheZcukNwJAMh5L2MR z5OWJXellV5iUAkvIS0pzFjBdCdv/WrmIHNRpUlLIVpD+goXqoIrfEjphPt5niGBbs WxFIrqyse2Yq47zg3p/N0zZ8Ia8FKJmofiTM9oLc= X-Authentication-Warning: raven.nostrum.com: Host mta-70-120-123-175.stx.rr.com [70.120.123.175] (may be forged) claimed to be bens-macbook.lan From: Ben Campbell Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_00EE1CC8-65CF-417F-848E-8EE5C12EF5B9" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) Date: Mon, 15 Jun 2020 13:02:31 -0500 In-Reply-To: Cc: Dispatch WG , sframe@ietf.org, Patrick McManus To: Emad Omara References: X-Mailer: Apple Mail (2.3608.80.23.2.2) Archived-At: Subject: Re: [Sframe] [dispatch] Request session at IETF 108 dispatch 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, 15 Jun 2020 18:02:48 -0000 --Apple-Mail=_00EE1CC8-65CF-417F-848E-8EE5C12EF5B9 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Emad, We prioritize DISPATCH meeting time to focus on topics that have had = DISPATCH list discussion and need high-bandwidth time to resolve. Unless = I=E2=80=99ve missed something, this topic has not previously come up in = DISPATCH. I suggest sending a note to this list with some background = about the draft and how you would like to see it progress. Thanks! Ben. > On Jun 15, 2020, at 12:32 PM, Emad Omara = wrote: >=20 > Hi, >=20 > We would like to have a session in the next IETF to discuss the SFrame = draft Can you please = help scheduling this? >=20 > Thanks > Emad > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch --Apple-Mail=_00EE1CC8-65CF-417F-848E-8EE5C12EF5B9 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi = Emad,

We prioritize = DISPATCH meeting time to focus on topics that have had DISPATCH list = discussion and need high-bandwidth time to resolve. Unless I=E2=80=99ve = missed something, this topic has not previously come up in DISPATCH. I = suggest sending a note to this list with some background about the draft = and how you would like to see it progress.

Thanks!

Ben.

On Jun = 15, 2020, at 12:32 PM, Emad Omara <emadomara=3D40google.com@dmarc.ietf.org> = wrote:

Hi,

We would like to have a session in the next IETF to discuss = the SFrame draft Can you please help scheduling = this?

Thanks
Emad
_______________________________________________
dispatch = mailing list
dispatch@ietf.org
https://www.ietf.org/mailman/listinfo/dispatch

= --Apple-Mail=_00EE1CC8-65CF-417F-848E-8EE5C12EF5B9-- From nobody Mon Jun 15 11:33:24 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 972123A0846 for ; Mon, 15 Jun 2020 11:33:22 -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 e0dCnufqUU2C for ; Mon, 15 Jun 2020 11:33:21 -0700 (PDT) Received: from mail-ej1-x634.google.com (mail-ej1-x634.google.com [IPv6:2a00:1450:4864:20::634]) (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 DD7C33A0838 for ; Mon, 15 Jun 2020 11:33:20 -0700 (PDT) Received: by mail-ej1-x634.google.com with SMTP id l12so18489336ejn.10 for ; Mon, 15 Jun 2020 11:33:20 -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=S+42B0sMuRzRUyhk2p/H6NJ0mMFM1Yb596K3W5LJSo4=; b=aXQJTP1Z5PAXl7LIE7pKvEylNotSIwDiIqWFB7Jd9FLD2RODNFRhMMIoY3wpVF6r4U gR9R8Eti3fEBTreHFZb3uy0IvittbSjSf7XEaHQFRXOjuw8XnYLjIy3/cLnz5brVd9+K dlXm1QlDG49z+d+8m5cLcvvoxJCJSAba9TihI/CD8aB6NaxONsdKT1NhMoWWG0vF+BIW 7Jg+LXg63bmyuUZ5WrvbCVXXWoihjwlASO6XLbBnjoKybfy5zpX0ya+uNNrRQ19cSYSk N6s6CIDJvz3Oy7bgZ1QkDzWlTuOEM6X4z9TCFN2rIrsOMhHmIpqCg8Fl9VU7pUiaKCPJ wbaQ== 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=S+42B0sMuRzRUyhk2p/H6NJ0mMFM1Yb596K3W5LJSo4=; b=LZduLXlpie8gh1zjGHNx8Sr1xrPVSBL2/1GUP6OWFzgfmUAeRDCSRCDmnDGRVHv4gh KM2QuI9+Fvsym7xvoizlGvIaegEKKK2aN5H8GwiVQzUbIvQTWU7AoJXMZuVoThMyHaYx wZCqL5cyYKpRJmR5xGWMWQIGSsFvR1X6qu7a8cUG4BeVjfJkBT0YA2neorG7hcQwO3v8 KqyZPXfBA7n5UonixTJPw3vq3zyrwncDxOOYV/zsbaTBYH2Yp6kat48SgrF8jp0UBvRJ P18GnJSZMJW363nVxREPZ2Y/XTdlFhbOJVSWd38NaR6rWl70qsD+WE0/RjcCG2hLzzJd YPXQ== X-Gm-Message-State: AOAM532uSA+VSsHBt0kDfOr64ZlK/Nq8TH0yilhRTy0Qrv9hsgGzS990 K8IvLWcRi3LKri7X+ZeIN5Wj2pWyq1oUHZiZHzp9 X-Google-Smtp-Source: ABdhPJyPfdGkyRtw4Hq21YOZvE9pe1sOpgZLnwyT2ZZahgtSgD0NPY7G2FP0TVDrSb4HkZ7uv4HKrVLZm2JkZtKugqY= X-Received: by 2002:a17:906:22d0:: with SMTP id q16mr14077150eja.455.1592245998943; Mon, 15 Jun 2020 11:33:18 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Emad Omara Date: Mon, 15 Jun 2020 11:33:07 -0700 Message-ID: To: Ben Campbell Cc: Dispatch WG , sframe@ietf.org, Patrick McManus Content-Type: multipart/alternative; boundary="00000000000029e31305a823a908" Archived-At: Subject: Re: [Sframe] [dispatch] Request session at IETF 108 dispatch 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, 15 Jun 2020 18:33:23 -0000 --00000000000029e31305a823a908 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Ben, This draft proposes a solution for end-to-end encrypted conference calls. We implemented this in Google a couple of years ago in Duo, but the draft was only published last month given the current interest in the topic. The goal of the session is to go through the proposal and see if there is interest to continue working on this, and if so what will be the best WG to host this work. Thanks Emad On Mon, Jun 15, 2020 at 11:02 AM Ben Campbell wrote: > Hi Emad, > > We prioritize DISPATCH meeting time to focus on topics that have had > DISPATCH list discussion and need high-bandwidth time to resolve. Unless > I=E2=80=99ve missed something, this topic has not previously come up in D= ISPATCH. I > suggest sending a note to this list with some background about the draft > and how you would like to see it progress. > > Thanks! > > Ben. > > On Jun 15, 2020, at 12:32 PM, Emad Omara < > emadomara=3D40google.com@dmarc.ietf.org> wrote: > > Hi, > > We would like to have a session in the next IETF to discuss the SFrame > draft Can you please > help scheduling this? > > Thanks > Emad > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > > > --00000000000029e31305a823a908 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Ben,

This draft proposes a solution = for end-to-end encrypted conference calls. We implemented=C2=A0this in Goog= le a couple of years ago in Duo, but the draft was only published last mont= h given the current interest in the topic.

The goa= l of the session is to go through the proposal and see if there is interest= to continue working on this, and if so what will be the best WG to host th= is work.=C2=A0

Thanks
Emad
On Mon, = Jun 15, 2020 at 11:02 AM Ben Campbell <ben@nostrum.com> wrote:
Hi Emad,
We prioritize DISPATCH meeting time to focus on topics that hav= e had DISPATCH list discussion and need high-bandwidth time to resolve. Unl= ess I=E2=80=99ve missed something, this topic has not previously come up in= DISPATCH. I suggest sending a note to this list with some background about= the draft and how you would like to see it progress.

<= div>Thanks!

Ben.

On Jun 15, 2020, at 12:32 PM, Emad Omara <emadomara=3D40goog= le.com@dmarc.ietf.org> wrote:

Hi,
We would like to have a session in the next IETF to discuss= the SFrame draft=C2=A0Can you please help scheduling this?

Thanks
Emad
_______________________________________________
dispatch mailing listdispatch@ietf.org
https://www.ietf.org/mailman/listinfo/dispatch

--00000000000029e31305a823a908-- From nobody Mon Jun 15 11:43:15 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 573F13A092D; Mon, 15 Jun 2020 11:43:13 -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 vvzgY635vSd6; Mon, 15 Jun 2020 11:43:10 -0700 (PDT) Received: from mail-ot1-x330.google.com (mail-ot1-x330.google.com [IPv6:2607:f8b0:4864:20::330]) (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 A5EF33A0926; Mon, 15 Jun 2020 11:43:10 -0700 (PDT) Received: by mail-ot1-x330.google.com with SMTP id g5so13916074otg.6; Mon, 15 Jun 2020 11:43:10 -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=i2v/d08OHEPd+AR18JS6apn9EPHprIGOZ2OIam59E4w=; b=RFeD8OIyYI+uTxxvJH8Dub5x2SU6fLGGYNcge4o/it6ytdE9yDvgs9+pRaHDl4S6DM R0n8PegyNi/orPbl4krgee0IMgCk3HP1/LjHG57ZahLikzIdALC9tvRwrZngj1fgOvGp EQ3D7lfVuoW5AjvMDQ13n+8nf2kw+Fc/odw25PS49GogqQRSKOYFLWpbiP0oehMK8Qvu n1JcQMbv8VXhI9ZsPt+PPR+5ei3eSPjwBcsABiypRZqo/3U+aXWeFerKjoTBL0plyc2o Up8u+3T2JA/gU3XdHJyPZ4TnOl6grzZRxQs4JylYJgCODYivfzvMd6NMoNw5KZR0liu/ h2ZA== 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=i2v/d08OHEPd+AR18JS6apn9EPHprIGOZ2OIam59E4w=; b=V1xAzK35OZjRfUsRIIfbNR6FtTGPKMksigA0j/Q94phm/UpjbkEK7CDW64tNnecKdo WydiRkH40gN5CA7Ei6pq/2wGY8KcLwLVlj2ta4x4pWZ0coCa7Y2sf1mEgRvHvfxQIjCS UeijzSqlA1xw1cNtQHvESusXcTbYf8VIYTuC4I/rI7xXaQvuTzvqkMj5jRekZnXqnUfC z+hc9XnY5vNbmtFqFMlEGhCNZCp2ubLEUshNUfcXWKUaSGsvQO9zuTm08iLtdUIEePkO Gp2X60PLQ13nUZO3kZoeKvrTuFxGjaLAlNDIHPlpg8F18CZIibyxHFkpE5zwkJw3hsRA nrdg== X-Gm-Message-State: AOAM532bmfOyoSbLs8eP5afiPPrl1LoQ8K4U11M/6n6APnK2X7gAcQ/h QchaoIUpm6CU0rafsaC2OJFLo2tamAdz2kYzRns= X-Google-Smtp-Source: ABdhPJxIR0Hix3uq9ryahDwXIhyvjpRXLsu7PVESqjnoQnhAsSfeeNgHcgUvhS1Hv81B9CgjvOzmaA5DCW1JcNT0fJQ= X-Received: by 2002:a9d:61ca:: with SMTP id h10mr9666005otk.154.1592246589838; Mon, 15 Jun 2020 11:43:09 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Patrick McManus Date: Mon, 15 Jun 2020 14:42:58 -0400 Message-ID: To: Emad Omara Cc: Ben Campbell , Dispatch WG , sframe@ietf.org Content-Type: multipart/alternative; boundary="00000000000061d98605a823cc6e" Archived-At: Subject: Re: [Sframe] [dispatch] Request session at IETF 108 dispatch 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, 15 Jun 2020 18:43:13 -0000 --00000000000061d98605a823cc6e Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Sounds really interesting Emad and there's obviously related work going on (at least perc, maybe even mls..). Sending that email Ben mentions to the dispatch list to raise awareness with a link to the draft would be helpful in getting the process started.. On Mon, Jun 15, 2020 at 2:33 PM Emad Omara wrote: > Hi Ben, > > This draft proposes a solution for end-to-end encrypted conference calls. > We implemented this in Google a couple of years ago in Duo, but the draft > was only published last month given the current interest in the topic. > > The goal of the session is to go through the proposal and see if there is > interest to continue working on this, and if so what will be the best WG = to > host this work. > > Thanks > Emad > > On Mon, Jun 15, 2020 at 11:02 AM Ben Campbell wrote: > >> Hi Emad, >> >> We prioritize DISPATCH meeting time to focus on topics that have had >> DISPATCH list discussion and need high-bandwidth time to resolve. Unless >> I=E2=80=99ve missed something, this topic has not previously come up in = DISPATCH. I >> suggest sending a note to this list with some background about the draft >> and how you would like to see it progress. >> >> Thanks! >> >> Ben. >> >> On Jun 15, 2020, at 12:32 PM, Emad Omara < >> emadomara=3D40google.com@dmarc.ietf.org> wrote: >> >> Hi, >> >> We would like to have a session in the next IETF to discuss the SFrame >> draft Can you please >> help scheduling this? >> >> Thanks >> Emad >> _______________________________________________ >> dispatch mailing list >> dispatch@ietf.org >> https://www.ietf.org/mailman/listinfo/dispatch >> >> >> --00000000000061d98605a823cc6e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Sounds really interesting Emad and there's obviously r= elated=C2=A0work going on (at least perc, maybe even mls..).

=
Sending that email Ben mentions to the dispatch list to raise awarenes= s with a link to the draft would be helpful in getting the process started.= .

On Mon, Jun 15, 2020 at 2:33 PM Emad Omara <emadomara@google.com> wrote:
Hi Ben,

This draft proposes a solution for end-to-end encrypted conference = calls. We implemented=C2=A0this in Google a couple of years ago in Duo, but= the draft was only published last month given the current interest in the = topic.

The goal of the session is to go through th= e proposal and see if there is interest to continue working on this, and if= so what will be the best WG to host this work.=C2=A0

<= div>Thanks
Emad

On Mon, Jun 15, 2020 at 11:02 AM Ben Campbel= l <ben@nostrum.com<= /a>> wrote:
<= div>Hi Emad,

--00000000000061d98605a823cc6e-- From nobody Mon Jun 15 12:06:02 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 8DC083A0958; Mon, 15 Jun 2020 12:06:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.096 X-Spam-Level: X-Spam-Status: No, score=-2.096 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, RCVD_IN_DNSWL_BLOCKED=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 QkZgmmfaIOYa; Mon, 15 Jun 2020 12:05:59 -0700 (PDT) Received: from mail-oi1-x22c.google.com (mail-oi1-x22c.google.com [IPv6:2607:f8b0: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 DEB593A0975; Mon, 15 Jun 2020 12:05:58 -0700 (PDT) Received: by mail-oi1-x22c.google.com with SMTP id i74so16938318oib.0; Mon, 15 Jun 2020 12:05:58 -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=8a4FoPWqjEn/8SuPin5DWTs/gxY0RxYgI2LlMTlLmLc=; b=AXLzZcCRDK0xvE+Hv1k1CDP7IGnlXzMheMAJE7RH4hvSLJehdWj8imxEz2ABYFCeD9 vgOB3BX9Ti0izQeKYaXfrv57yCxW96pl5eX0JgAO/urF5ncGNxfuLfc4bluceIwCZo48 N7WBj1C0SvIDAfYFfirQ6mYx2fNh1Hq8jtF3Zv+DUCgZimly+vQAFJCs94BvnMlIt1/O gFCJfAFoWwhxdSjSmcXlsbRXa+gI48Vw5IbRivmxgu6mHLS3EXTqIMYhTVhcD8btanAh 7fBmrP459PhrVZB8lfWp99h0fZCsh5dwMqP7+Spa23t+Ajknn8qdCLTxDlwfRMSETPFv zaTg== 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=8a4FoPWqjEn/8SuPin5DWTs/gxY0RxYgI2LlMTlLmLc=; b=ktLsy8/khx0WjMUp/UZCLK2mtMS3d5WyydnXRK84YcnG6OdIiZ0XIElk9X0dw4GYm0 Z/Mwb7PLy0ro/j3YG0Q0o+YkP0qDQalJJakkInFtgKwNnj+76HJXtMNlQw5BO5bXqL1n NigdN8LSWgOzSGXoqAsia80UOFhnSA7YiaRiP3V/SHmODS/f0J9AlFSYGp9Jk4d9UuwQ ZK5ek5tVqUS2ylU3VaQ3Iq1TAV5t/w6DwqWruzNRRCCegqjliVApJT5+MxNW/LCTa/P+ rIJA+D4kgPMmXYTXY5tBL8BPqdGFPP4CdR28rzuGKcq8XEyL+FnaI2q52Dd4NETHQt9+ mK1g== X-Gm-Message-State: AOAM5334v8s1khRte85alghX7t0OcfTZIYUthtyGKEe2bEpEeRpS4iiv qPfPHvuS3eAOVOl50sg99r5o0isy8xLhURlBKCA= X-Google-Smtp-Source: ABdhPJzSHexTDKNi6UWt2lS4sFlU3izbQzhwFcj/rvCZEBbKJlxDEwRn4VMAqENM/Idx7RH05OS11khpq5vP0jBJRoU= X-Received: by 2002:aca:b357:: with SMTP id c84mr667974oif.118.1592247958114; Mon, 15 Jun 2020 12:05:58 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Patrick McManus Date: Mon, 15 Jun 2020 15:05:47 -0400 Message-ID: To: Emad Omara Cc: Ben Campbell , Dispatch WG , sframe@ietf.org Content-Type: multipart/alternative; boundary="000000000000f0173005a8241dbc" Archived-At: Subject: [Sframe] Dispatch of SFrame for End-To-End Encrypted Conference Calls 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, 15 Jun 2020 19:06:01 -0000 --000000000000f0173005a8241dbc Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi All - I failed to note the link highlighting in Emad's mail to the list which already contained the draft. Sorry about that. (It's https://tools.ietf.org/html/draft-omara-sframe-00 if you too missed it). There's also a github and mailing list referenced: https://github.com/eomara/sframe https://mailarchive.ietf.org/arch/browse/sframe/? [I've also forked the Subject Line to help interested readers] On Mon, Jun 15, 2020 at 2:42 PM Patrick McManus wrote: > Sounds really interesting Emad and there's obviously related work going o= n > (at least perc, maybe even mls..). > > Sending that email Ben mentions to the dispatch list to raise awareness > with a link to the draft would be helpful in getting the process started.= . > > On Mon, Jun 15, 2020 at 2:33 PM Emad Omara wrote: > >> Hi Ben, >> >> This draft proposes a solution for end-to-end encrypted conference calls= . >> We implemented this in Google a couple of years ago in Duo, but the draf= t >> was only published last month given the current interest in the topic. >> >> The goal of the session is to go through the proposal and see if there i= s >> interest to continue working on this, and if so what will be the best WG= to >> host this work. >> >> Thanks >> Emad >> >> On Mon, Jun 15, 2020 at 11:02 AM Ben Campbell wrote: >> >>> Hi Emad, >>> >>> We prioritize DISPATCH meeting time to focus on topics that have had >>> DISPATCH list discussion and need high-bandwidth time to resolve. Unles= s >>> I=E2=80=99ve missed something, this topic has not previously come up in= DISPATCH. I >>> suggest sending a note to this list with some background about the draf= t >>> and how you would like to see it progress. >>> >>> Thanks! >>> >>> Ben. >>> >>> On Jun 15, 2020, at 12:32 PM, Emad Omara < >>> emadomara=3D40google.com@dmarc.ietf.org> wrote: >>> >>> Hi, >>> >>> We would like to have a session in the next IETF to discuss the SFrame >>> draft Can you >>> please help scheduling this? >>> >>> Thanks >>> Emad >>> _______________________________________________ >>> dispatch mailing list >>> dispatch@ietf.org >>> https://www.ietf.org/mailman/listinfo/dispatch >>> >>> >>> --000000000000f0173005a8241dbc Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi All -

I failed to note the link= highlighting in Emad's mail to the list which already contained the dr= aft. Sorry about that. (It's=C2=A0https://tools.ietf.org/html/draft-omara-sframe-00<= /a>=C2=A0if you too missed it).

There's also a github and mailin= g list referenced:
https://= github.com/eomara/sframe
https://mailarchive.ietf.org/arch/browse/sframe/?

[I've also forked the Subject Line to help interes= ted readers]

On Mon, Jun 15, 2020 at 2:42 PM Patrick McManus <patrick.ducksong@gmail.com>= wrote:
Sounds really interesting Emad and there's obviously related= =C2=A0work going on (at least perc, maybe even mls..).

S= ending that email Ben mentions to the dispatch list to raise awareness with= a link to the draft would be helpful in getting the process started..

On Mon, Jun 15, 2020 at 2:33 PM Emad Omara <emadomara@google.com> wrote:
Hi Ben,=

This draft proposes a solution for end-to-end encrypted= conference calls. We implemented=C2=A0this in Google a couple of years ago= in Duo, but the draft was only published last month given the current inte= rest in the topic.

The goal of the session is to g= o through the proposal and see if there is interest to continue working on = this, and if so what will be the best WG to host this work.=C2=A0

Thanks
Emad

On Mon, Jun 15, 2020 at 11:02 AM= Ben Campbell <ben@= nostrum.com> wrote:
Hi Emad,

We prioritize DISPATCH meeting = time to focus on topics that have had DISPATCH list discussion and need hig= h-bandwidth time to resolve. Unless I=E2=80=99ve missed something, this top= ic has not previously come up in DISPATCH. I suggest sending a note to this= list with some background about the draft and how you would like to see it= progress.

Thanks!

Ben.

On Jun 15, 2020, at 12:32 PM, Ema= d Omara <emadomara=3D40google.com@dmarc.ietf.org> wrote:
<= br>
Hi,

We would like to have a ses= sion in the next IETF to discuss the SFrame draft=C2=A0Can you ple= ase help scheduling this?

Thanks
Emad
_______________________________________________
dispatch mailing listdispatch@ietf.org
https://www.ietf.org/mailman/listinfo/dispatch

--000000000000f0173005a8241dbc-- From nobody Mon Jun 15 12:13:23 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 71C473A0C94; Mon, 15 Jun 2020 12:13:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.676 X-Spam-Level: X-Spam-Status: No, score=-1.676 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, HTML_MESSAGE=0.001, MAY_BE_FORGED=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=nostrum.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 LdoCwqwpNGvG; Mon, 15 Jun 2020 12:13:16 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (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 E2A173A0C93; Mon, 15 Jun 2020 12:13:15 -0700 (PDT) Received: from bens-macbook.lan (mta-70-120-123-175.stx.rr.com [70.120.123.175] (may be forged)) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id 05FJD8U8090099 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Mon, 15 Jun 2020 14:13:09 -0500 (CDT) (envelope-from ben@nostrum.com) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nostrum.com; s=default; t=1592248390; bh=sTUerH3PZbJZxIzZ+L4zTozKdsYyROqW2O1mr2ynnRo=; h=From:Subject:Date:In-Reply-To:Cc:To:References; b=fYJQ3BRo7w4sTpoP6jmdPYAS3CU0IEzzxc3uACCNybBwDZWgbYawD74+SUEK/eUt8 wMIJ0pl0uyynwyipea1soqlr0jklAIIBEj6kQDIE5OZXCrVMjIG4TNBpFRd3jYgNtU mt+ksrV/5WRlcAtWkp8gXq6B7MxA1BYWiJezNT6c= X-Authentication-Warning: raven.nostrum.com: Host mta-70-120-123-175.stx.rr.com [70.120.123.175] (may be forged) claimed to be bens-macbook.lan From: Ben Campbell Message-Id: <4425D473-7A6A-4AF5-BA53-635255D6EC55@nostrum.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_E949626B-39E1-4C79-8B8B-9F526A7869E8" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) Date: Mon, 15 Jun 2020 14:13:02 -0500 In-Reply-To: Cc: Emad Omara , Dispatch WG , sframe@ietf.org To: Patrick McManus References: X-Mailer: Apple Mail (2.3608.80.23.2.2) Archived-At: Subject: Re: [Sframe] Dispatch of SFrame for End-To-End Encrypted Conference Calls 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, 15 Jun 2020 19:13:18 -0000 --Apple-Mail=_E949626B-39E1-4C79-8B8B-9F526A7869E8 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Thanks, Patrick. Authors: It would be helpful to get a little more background:=20 - How does this work relate to PERC? What problem does it solve that = PERC doesn=E2=80=99t? - Do you expect this to become an IETF standard available to anyone to = implement? Who do you think would implement it?=20 - Is anyone outside of Google working on the spec or implementing the = protocol? Has anyone outside of Google expressed interest in doing so? - Anything else you think would help motivate people to read the draft = and give feedback :-) Thanks! Ben. > On Jun 15, 2020, at 2:05 PM, Patrick McManus = wrote: >=20 > Hi All - >=20 > I failed to note the link highlighting in Emad's mail to the list = which already contained the draft. Sorry about that. (It's = https://tools.ietf.org/html/draft-omara-sframe-00 = if you too missed = it). >=20 > There's also a github and mailing list referenced: > https://github.com/eomara/sframe > https://mailarchive.ietf.org/arch/browse/sframe/? = >=20 > [I've also forked the Subject Line to help interested readers] >=20 > On Mon, Jun 15, 2020 at 2:42 PM Patrick McManus = > wrote: > Sounds really interesting Emad and there's obviously related work = going on (at least perc, maybe even mls..). >=20 > Sending that email Ben mentions to the dispatch list to raise = awareness with a link to the draft would be helpful in getting the = process started.. >=20 > On Mon, Jun 15, 2020 at 2:33 PM Emad Omara > wrote: > Hi Ben, >=20 > This draft proposes a solution for end-to-end encrypted conference = calls. We implemented this in Google a couple of years ago in Duo, but = the draft was only published last month given the current interest in = the topic. >=20 > The goal of the session is to go through the proposal and see if there = is interest to continue working on this, and if so what will be the best = WG to host this work.=20 >=20 > Thanks > Emad >=20 > On Mon, Jun 15, 2020 at 11:02 AM Ben Campbell > wrote: > Hi Emad, >=20 > We prioritize DISPATCH meeting time to focus on topics that have had = DISPATCH list discussion and need high-bandwidth time to resolve. Unless = I=E2=80=99ve missed something, this topic has not previously come up in = DISPATCH. I suggest sending a note to this list with some background = about the draft and how you would like to see it progress. >=20 > Thanks! >=20 > Ben. >=20 >> On Jun 15, 2020, at 12:32 PM, Emad Omara = > wrote: >>=20 >> Hi, >>=20 >> We would like to have a session in the next IETF to discuss the = SFrame draft Can you = please help scheduling this? >>=20 >> Thanks >> Emad >> _______________________________________________ >> dispatch mailing list >> dispatch@ietf.org >> https://www.ietf.org/mailman/listinfo/dispatch = >=20 --Apple-Mail=_E949626B-39E1-4C79-8B8B-9F526A7869E8 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Thanks, Patrick.

Authors: It would be helpful to get a little more = background: 

- How does this work relate to PERC? What problem does it = solve that PERC doesn=E2=80=99t?
- Do you expect = this to become an IETF standard available to anyone to implement? Who do = you think would implement it? 
- Is anyone = outside of Google working on the spec or implementing the protocol? Has = anyone outside of Google expressed interest in doing so?
- Anything else you think would help motivate people to read = the draft and give feedback :-)

Thanks!

Ben.

On Jun 15, 2020, at 2:05 PM, Patrick McManus = <patrick.ducksong@gmail.com> wrote:

Hi All -

I failed to note the link highlighting in Emad's mail to the = list which already contained the draft. Sorry about that. (It's https://tools.ietf.org/html/draft-omara-sframe-00 if = you too missed it).

There's also a github = and mailing list referenced:
https://github.com/eomara/sframe
https://mailarchive.ietf.org/arch/browse/sframe/?

[I've = also forked the Subject Line to help interested readers]

On Mon, Jun 15, 2020 at 2:42 PM Patrick McManus = <patrick.ducksong@gmail.com> wrote:
Sounds = really interesting Emad and there's obviously related work going on = (at least perc, maybe even mls..).

Sending that email Ben mentions to the = dispatch list to raise awareness with a link to the draft would be = helpful in getting the process started..

On Mon, Jun = 15, 2020 at 2:33 PM Emad Omara <emadomara@google.com> wrote:
Hi = Ben,

This draft = proposes a solution for end-to-end encrypted conference calls. We = implemented this in Google a couple of years ago in Duo, but the = draft was only published last month given the current interest in the = topic.

The = goal of the session is to go through the proposal and see if there is = interest to continue working on this, and if so what will be the best WG = to host this work. 

Thanks
Emad

On Mon, Jun = 15, 2020 at 11:02 AM Ben Campbell <ben@nostrum.com> wrote:
Hi Emad,

We prioritize DISPATCH = meeting time to focus on topics that have had DISPATCH list discussion = and need high-bandwidth time to resolve. Unless I=E2=80=99ve missed = something, this topic has not previously come up in DISPATCH. I suggest = sending a note to this list with some background about the draft and how = you would like to see it progress.

Thanks!

Ben.

On Jun = 15, 2020, at 12:32 PM, Emad Omara <emadomara=3D40google.com@dmarc.ietf.org> = wrote:

Hi,

We = would like to have a session in the next IETF to discuss the SFrame draft Can you please help = scheduling this?

Thanks
Emad
_______________________________________________
dispatch = mailing list
dispatch@ietf.org
https://www.ietf.org/mailman/listinfo/dispatch


= --Apple-Mail=_E949626B-39E1-4C79-8B8B-9F526A7869E8-- From nobody Mon Jun 15 12:20:45 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 BE4343A0CE3 for ; Mon, 15 Jun 2020 12:20:44 -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, RCVD_IN_DNSWL_NONE=-0.0001, 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 J1sp1fEjftqZ for ; Mon, 15 Jun 2020 12:20:42 -0700 (PDT) Received: from mail-ed1-x534.google.com (mail-ed1-x534.google.com [IPv6:2a00:1450:4864:20::534]) (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 9803A3A0CE0 for ; Mon, 15 Jun 2020 12:20:42 -0700 (PDT) Received: by mail-ed1-x534.google.com with SMTP id g1so12353596edv.6 for ; Mon, 15 Jun 2020 12:20:42 -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=GfxJedznmf2If8mWtVOIgELXnAT/bMiy+EnCZ7gIqQM=; b=vw5mzSPKVa90s3LheNs/GN1u5fcR3PfV/mE1gODQLh6023KTmLZGuFNvcqBA3pUoON QiX4loerpX+xaxK7Uhe4AN3Sm6Wgx2TpgvvdSVcg6CFxAJQdEkVTWRyZ+142KUZOfH9T NHQ2UtL3uEqeO0HuJRfkU3c5YHeD8KHKJtLUHSFx2BDQyh5Ripu3CkQ0r8j16DUI53on vDqvAtUVYEIDRBk+vbKAspW4p54cr7WmWiROLGqfxR99kO3bixhwwXGVO6UDZz8+xd6J lFyDrMZgoeiNJIeKt1vPGrmjxxCu1HSQVUcndY78KTZTuwNziMsliB0O/PsBwyUHh00c ElBw== 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=GfxJedznmf2If8mWtVOIgELXnAT/bMiy+EnCZ7gIqQM=; b=Jr4fStlxd5M0kPR57KbpyA4s+Npt4BYmnBgx2LxQNZUVgCcuGv8GWJgRP9ihJ/wVWf nTKfcAA1eZ+/82D6i7p8/L0o51mhxl0fZtwJ2VS9qcPjeY6D2v7zn9ZpG9YTa7qezmz+ tnLJUIHEKF0H92wEHiKHOeABeSgOx1G9ePNtIxkq7hXHQdI8b2hNVRGY3QIi3BEW6/dR qKBXcMIz21bxzTjWIZMjquOjznq7koseiTH8+QNQ+qSLtEMdtE7V00zWSeBrXBGloAfx 6c2TJjS0+wtB7sT6p62qiI/ZfB2mByTYQ9UtZexqwDT7cOkC0jr3Xj2oTXIX769wIFjJ TkAg== X-Gm-Message-State: AOAM533WuAyprYAlOJAMGEmPjq1x2mVCPr+jejSGchfaW9ZqjIijb4Bx S7oS0RpqA5+TNA2kCGg75UhgNyCax8zwFfidWRsJ X-Google-Smtp-Source: ABdhPJwSeQVh+ac72SQN3bt4Eyyh+6RdeMUBuYTztgHDFhe0Ne8Ce7yotGE/hpA1PhPqKR1mEQ1VpVjfM1JcOjcfQ5E= X-Received: by 2002:aa7:cb94:: with SMTP id r20mr25514539edt.215.1592248840601; Mon, 15 Jun 2020 12:20:40 -0700 (PDT) MIME-Version: 1.0 References: <4425D473-7A6A-4AF5-BA53-635255D6EC55@nostrum.com> In-Reply-To: <4425D473-7A6A-4AF5-BA53-635255D6EC55@nostrum.com> From: Emad Omara Date: Mon, 15 Jun 2020 12:20:29 -0700 Message-ID: To: Ben Campbell , Sergio murillo , Alexandre GOUAILLARD Cc: Patrick McManus , Dispatch WG , sframe@ietf.org Content-Type: multipart/alternative; boundary="0000000000008a3de905a82452be" Archived-At: Subject: Re: [Sframe] Dispatch of SFrame for End-To-End Encrypted Conference Calls 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, 15 Jun 2020 19:20:45 -0000 --0000000000008a3de905a82452be Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Thanks. Some responses inline. Other authors please feel free to add more. Emad On Mon, Jun 15, 2020 at 12:13 PM Ben Campbell wrote: > Thanks, Patrick. > > Authors: It would be helpful to get a little more background: > > - How does this work relate to PERC? What problem does it solve that PERC > doesn=E2=80=99t? > This is a completely different approach than PERC. THis draft aims for simplicity and efficiency. The sdrame draft itself has some benchmarks against the PERC approach. That being said the sframe draft focuses mainly on the media encryption part and touches slightly other parts in the system like key management and integration with WebRTC. If this became a standard we will have to write a separate draft for each of these two topics. > - Do you expect this to become an IETF standard available to anyone to > implement? Who do you think would implement it? > Yes. This will be implemented by the video conference providers. The core protocol implementation is on the client side. > - Is anyone outside of Google working on the spec or implementing the > protocol? Has anyone outside of Google expressed interest in doing so? > Yes, the document is co-authored by +Sergio murillo & +Alexandre GOUAILLARD from Cosmos Software. > - Anything else you think would help motivate people to read the draft an= d > give feedback :-) > > Thanks! > > Ben. > > On Jun 15, 2020, at 2:05 PM, Patrick McManus > wrote: > > Hi All - > > I failed to note the link highlighting in Emad's mail to the list which > already contained the draft. Sorry about that. (It's > https://tools.ietf.org/html/draft-omara-sframe-00 if you too missed it). > > There's also a github and mailing list referenced: > https://github.com/eomara/sframe > https://mailarchive.ietf.org/arch/browse/sframe/? > > [I've also forked the Subject Line to help interested readers] > > On Mon, Jun 15, 2020 at 2:42 PM Patrick McManus < > patrick.ducksong@gmail.com> wrote: > >> Sounds really interesting Emad and there's obviously related work going >> on (at least perc, maybe even mls..). >> >> Sending that email Ben mentions to the dispatch list to raise awareness >> with a link to the draft would be helpful in getting the process started= .. >> >> On Mon, Jun 15, 2020 at 2:33 PM Emad Omara wrote: >> >>> Hi Ben, >>> >>> This draft proposes a solution for end-to-end encrypted conference >>> calls. We implemented this in Google a couple of years ago in Duo, but = the >>> draft was only published last month given the current interest in the t= opic. >>> >>> The goal of the session is to go through the proposal and see if there >>> is interest to continue working on this, and if so what will be the bes= t WG >>> to host this work. >>> >>> Thanks >>> Emad >>> >>> On Mon, Jun 15, 2020 at 11:02 AM Ben Campbell wrote: >>> >>>> Hi Emad, >>>> >>>> We prioritize DISPATCH meeting time to focus on topics that have had >>>> DISPATCH list discussion and need high-bandwidth time to resolve. Unle= ss >>>> I=E2=80=99ve missed something, this topic has not previously come up i= n DISPATCH. I >>>> suggest sending a note to this list with some background about the dra= ft >>>> and how you would like to see it progress. >>>> >>>> Thanks! >>>> >>>> Ben. >>>> >>>> On Jun 15, 2020, at 12:32 PM, Emad Omara < >>>> emadomara=3D40google.com@dmarc.ietf.org> wrote: >>>> >>>> Hi, >>>> >>>> We would like to have a session in the next IETF to discuss the SFrame >>>> draft Can you >>>> please help scheduling this? >>>> >>>> Thanks >>>> Emad >>>> _______________________________________________ >>>> dispatch mailing list >>>> dispatch@ietf.org >>>> https://www.ietf.org/mailman/listinfo/dispatch >>>> >>>> >>>> > --0000000000008a3de905a82452be Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thanks.

Some responses inline. Ot= her authors please feel free to add more.

Emad

On Mo= n, Jun 15, 2020 at 12:13 PM Ben Campbell <ben@nostrum.com> wrote:
Thanks, Patri= ck.

Authors: It would be helpful to get a little more ba= ckground:=C2=A0

- How does this work relate to PER= C? What problem does it solve that PERC doesn=E2=80=99t?
This is a completely different approach than PERC. THis draft ai= ms for simplicity and efficiency. The sdrame draft itself has some benchmar= ks against the PERC approach.=C2=A0 That being said the sframe draft focuse= s mainly on the media encryption part and touches slightly other parts in t= he system like key management and integration with WebRTC. If this became a= standard we will have to write a separate=C2=A0draft for each of these two= topics.=C2=A0
- Do you expect this to become an= IETF standard available to anyone to implement? Who do you think would imp= lement it?=C2=A0
Yes. This will be implemented= =C2=A0by the=C2=A0 video conference providers. The core protocol implementa= tion is on the client side.
- Is anyone outside = of Google working on the spec or implementing the protocol? Has anyone outs= ide of Google expressed interest in doing so?
= Yes, the document is co-authored by=C2=A0+Sergio murillo=C2=A0&=C2=A0+Alexandre GOUAILLARD=C2=A0from Cosmos Software.=C2=A0=
- Anything else you think would help motivate p= eople to read the draft and give feedback :-)

Than= ks!

Ben.

On Jun 15, 2020, at 2:05 PM, Patrick McManus <patrick.ducksong@= gmail.com> wrote:

Hi= All -

I failed to note the link highlighting in Emad's mail to = the list which already contained the draft. Sorry about that. (It's=C2= =A0https://tools.ietf.org/html/draft-omara-sframe-00=C2=A0if you t= oo missed it).

There's also a github and mailing list referenced= :
https:/= /github.com/eomara/sframe
https://mailarchive.ietf.org/arch/bro= wse/sframe/?

[I've also forked the Subject L= ine to help interested readers]

<= div dir=3D"ltr" class=3D"gmail_attr">On Mon, Jun 15, 2020 at 2:42 PM Patric= k McManus <patrick.ducksong@gmail.com> wrote:
Sounds really interesting Ema= d and there's obviously related=C2=A0work going on (at least perc, mayb= e even mls..).

Sending that email Ben mentions to the di= spatch list to raise awareness with a link to the draft would be helpful in= getting the process started..

On Mon, Jun 15, 2020 at 2:33 PM Emad Om= ara <emadomara= @google.com> wrote:
Hi Ben,

This draft proposes = a solution for end-to-end encrypted conference calls. We implemented=C2=A0t= his in Google a couple of years ago in Duo, but the draft was only publishe= d last month given the current interest in the topic.

<= div>The goal of the session is to go through the proposal and see if there = is interest to continue working on this, and if so what will be the best WG= to host this work.=C2=A0

Thanks
Emad

On Mon, Jun 15, 2020 at 11:02 AM Ben Campbell <ben@nostrum.com> wrote:
Hi Emad,

<= div>We prioritize DISPATCH meeting time to focus on topics that have had DI= SPATCH list discussion and need high-bandwidth time to resolve. Unless I=E2= =80=99ve missed something, this topic has not previously come up in DISPATC= H. I suggest sending a note to this list with some background about the dra= ft and how you would like to see it progress.

Than= ks!

Ben.

On Jun 15, 2020, at 12:32 PM, Emad Omara <emadomara=3D40google.com@= dmarc.ietf.org> wrote:

Hi,

We would like to have a session in the next IETF to discuss the SFrame draft=C2=A0Can you please help scheduling this?
Thanks
Emad
_______________________________________________
dispatch mailing listdispatch@ietf.org
https://www.ietf.org/mailman/listinfo/dispatch


--0000000000008a3de905a82452be-- From nobody Mon Jun 15 12:29:31 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 0BAA23A0914 for ; Mon, 15 Jun 2020 12:29:30 -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 yIPTloND6fTL for ; Mon, 15 Jun 2020 12:29:28 -0700 (PDT) Received: from mail-qv1-xf2b.google.com (mail-qv1-xf2b.google.com [IPv6:2607:f8b0:4864:20::f2b]) (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 301F33A08FC for ; Mon, 15 Jun 2020 12:29:28 -0700 (PDT) Received: by mail-qv1-xf2b.google.com with SMTP id er17so8319627qvb.8 for ; Mon, 15 Jun 2020 12:29:28 -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=usmSYOdrwAP4QhCy2FKKUHSQsgQ641y04x27a6Q08zo=; b=FFX3QlBoe+FWt0QSE0jzpySi/ZKZ3+aqf/97hZ3tQXCtEUZq7ZpWrr1fs351f/Cb4C xAtfosWoiiHePD/vtsVV90AM5iIATSiOkgVkhrD+KToUL0anQRQGOC17aa310OU2Accf NZGT46TtH3dvXY1jqyzsekU0uHpSPRjozxnuo8ztrfloAnm7OlGk2niqMZxCDVPP5PmY ovWNeyx8elKtRLryKBV6pE150xZqjgBuLLO/Ut14fDVbbbJ0QsqZOM+PbH2nQlnDUwe9 NafhcxtMqtHko6H5Xb+QZ5WX/ASF66r46ELqq7DhN79y3YveEG+WlXBNMgrm9UzWObUO 0X7A== 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=usmSYOdrwAP4QhCy2FKKUHSQsgQ641y04x27a6Q08zo=; b=QDbMRPmrrieFHQmvU4L7YEjeBHLy4G6PjbXGdY37bcRCbSTHuWc9x67UNYo3setdYJ 1jNm9io7QM8p1y3nL231BBaVeHbtLQ1rq4S75hubfwmJc5aP1Fb4LdfpPozu7BNFRzgn z46TsA073ohE2y9DetLNYfLOlfTPWoIdrdLgYIr59ykQIfsNUs1imfzGMqXj2hmkkDiN ijKUdjY+vRFv00hwdnH9T4RaUpiUVCFQmbfnuABtvz8i0iH9/pPI9PPLIGSX5XEr1vYX Hddo7H51/kVgHtcvEorfOQkzrLesSOC/NjN5lO495UrY7ExFlQwbJDgHMk27k7Pxxb3x 1/6A== X-Gm-Message-State: AOAM533/bShBbrmbDK0A8Apjr2FTeirm4kIuvNJan3ftRgEWOxBg4MQ2 1nlwJnkpQ96XpNsqYxmVCTcdi9ld+ZjbxgjbLFfQlQ== X-Google-Smtp-Source: ABdhPJwy+/0jfk1j7N6SP8sUJhNki1R2HXtSxzj8xjoDknZHdVT6upW09VreXttTSUQgfk/No30uNNCN0H0dtccyTLQ= X-Received: by 2002:a0c:8482:: with SMTP id m2mr27024380qva.65.1592249366986; Mon, 15 Jun 2020 12:29:26 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Richard Barnes Date: Mon, 15 Jun 2020 15:29:11 -0400 Message-ID: To: Patrick McManus Cc: Emad Omara , Ben Campbell , Dispatch WG , sframe@ietf.org Content-Type: multipart/alternative; boundary="000000000000e9d2bc05a8247197" Archived-At: Subject: Re: [Sframe] [dispatch] Request session at IETF 108 dispatch 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, 15 Jun 2020 19:29:30 -0000 --000000000000e9d2bc05a8247197 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable To address the related work point: You're correct that PERC is the main touch point, MLS less so; also RTCWeb if that were still going on. Very directly, this work is doing basically the same thing as PERC double encryption (RFC 8723). The key difference is decoupling between the hop-by-hop and end-to-end security contexts. In PERC, the E2E context uses some information from the HBH SRTP packet. So the fields used by the E2E context have to be unmodified, well, end to end, so that a clean media path is a prerequisite for E2E. (Where "clean" means "don't modify" or "modify in accordance with PERC") This dependency makes it much harder to deploy E2E in practices. In addition, once the E2E layer is decoupled from the HBH layer, it is much easier to transmit it over alternative HBH-secure transports, such as QUIC datagrams, WebTransport, or RIPT. FWIW, if I were to suggest a DISPATCH outcome, a focused WG seems like the right level of attention to me. The topic is worth working on and would benefit from an IETF-consensus specification, but the document isn't yet mature enough for AD sponsorship. --Richard On Mon, Jun 15, 2020 at 2:43 PM Patrick McManus wrote: > Sounds really interesting Emad and there's obviously related work going o= n > (at least perc, maybe even mls..). > > Sending that email Ben mentions to the dispatch list to raise awareness > with a link to the draft would be helpful in getting the process started.= .. > > On Mon, Jun 15, 2020 at 2:33 PM Emad Omara wrote: > >> Hi Ben, >> >> This draft proposes a solution for end-to-end encrypted conference calls= . >> We implemented this in Google a couple of years ago in Duo, but the draf= t >> was only published last month given the current interest in the topic. >> >> The goal of the session is to go through the proposal and see if there i= s >> interest to continue working on this, and if so what will be the best WG= to >> host this work. >> >> Thanks >> Emad >> >> On Mon, Jun 15, 2020 at 11:02 AM Ben Campbell wrote: >> >>> Hi Emad, >>> >>> We prioritize DISPATCH meeting time to focus on topics that have had >>> DISPATCH list discussion and need high-bandwidth time to resolve. Unles= s >>> I=E2=80=99ve missed something, this topic has not previously come up in= DISPATCH. I >>> suggest sending a note to this list with some background about the draf= t >>> and how you would like to see it progress. >>> >>> Thanks! >>> >>> Ben. >>> >>> On Jun 15, 2020, at 12:32 PM, Emad Omara < >>> emadomara=3D40google.com@dmarc.ietf.org> wrote: >>> >>> Hi, >>> >>> We would like to have a session in the next IETF to discuss the SFrame >>> draft Can you >>> please help scheduling this? >>> >>> Thanks >>> Emad >>> _______________________________________________ >>> dispatch mailing list >>> dispatch@ietf.org >>> https://www.ietf.org/mailman/listinfo/dispatch >>> >>> >>> -- > Sframe mailing list > Sframe@ietf.org > https://www.ietf.org/mailman/listinfo/sframe > --000000000000e9d2bc05a8247197 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
To address the related work point:

You're correct that PERC is the main touch point, MLS less so; a= lso RTCWeb if that were still going on.=C2=A0 Very directly, this work is d= oing basically the same thing as PERC double encryption (RFC 8723).=C2=A0 T= he key difference is decoupling between the hop-by-hop and end-to-end secur= ity contexts.=C2=A0 In PERC, the E2E context uses some information from the= HBH SRTP packet.=C2=A0 So the fields used by the E2E context have to be un= modified, well, end to end, so that a clean media path is a prerequisite fo= r E2E.=C2=A0 (Where "clean" means "don't modify" or= "modify in accordance with PERC")=C2=A0 This dependency makes it= much harder to deploy E2E in practices.=C2=A0 In addition, once the E2E la= yer is decoupled from the HBH layer, it is much easier to transmit it over = alternative HBH-secure transports, such as QUIC datagrams, WebTransport, or= RIPT.

FWIW, if I were to suggest a DISPATCH outco= me, a focused WG seems like the right level of attention to me.=C2=A0 The t= opic is worth working on and would benefit from an IETF-consensus specifica= tion, but the document isn't yet mature enough for AD sponsorship.

--Richard



On Mo= n, Jun 15, 2020 at 2:43 PM Patrick McManus <patrick.ducksong@gmail.com> wrote:
Sounds really = interesting Emad and there's obviously related=C2=A0work going on (at l= east perc, maybe even mls..).

Sending that email Ben men= tions to the dispatch list to raise awareness with a link to the draft woul= d be helpful in getting the process started...

On Mon, Jun 15, 2020 at= 2:33 PM Emad Omara <emadomara@google.com> wrote:
Hi Ben,

This= draft proposes a solution for end-to-end encrypted conference calls. We im= plemented=C2=A0this in Google a couple of years ago in Duo, but the draft w= as only published last month given the current interest in the topic.
=

The goal of the session is to go through the proposal a= nd see if there is interest to continue working on this, and if so what wil= l be the best WG to host this work.=C2=A0

Thanks
Emad

On Mon, Jun 15, 2020 at 11:02 AM Ben Campbell <ben@nostrum.com> wrot= e:
Hi Emad,=

We prioritize DISPATCH meeting time to focus on topics = that have had DISPATCH list discussion and need high-bandwidth time to reso= lve. Unless I=E2=80=99ve missed something, this topic has not previously co= me up in DISPATCH. I suggest sending a note to this list with some backgrou= nd about the draft and how you would like to see it progress.
Thanks!

Ben.

On Jun 15, 2020, at 12:32 PM, Emad Omara <emadomara= =3D40google.com@dmarc.ietf.org> wrote:

Hi,

We would like to have a session in the next IETF t= o discuss the SFrame draft=C2=A0Can you please help scheduling thi= s?

Thanks
Emad
_______________________________________________
dispatch mailing listdispatch@ietf.org
https://www.ietf.org/mailman/listinfo/dispatch

--
Sframe mailing list
Sframe@ietf.org https://www.ietf.org/mailman/listinfo/sframe
--000000000000e9d2bc05a8247197-- From nobody Mon Jun 15 12:30: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 CC7E03A091C for ; Mon, 15 Jun 2020 12:30:30 -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 jWPQLdVTWu2o for ; Mon, 15 Jun 2020 12:30:29 -0700 (PDT) Received: from mail-qk1-x72c.google.com (mail-qk1-x72c.google.com [IPv6:2607:f8b0:4864:20::72c]) (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 027983A08FC for ; Mon, 15 Jun 2020 12:30:28 -0700 (PDT) Received: by mail-qk1-x72c.google.com with SMTP id w1so16911522qkw.5 for ; Mon, 15 Jun 2020 12:30:28 -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=LeNI+1yuLit3/ZWjjJEGC312MJLgqZEh0xA2ccRhqdU=; b=k9ghVVZh7l+bYKjMniVq9UQTl/yQ33JPZj9uOCC6avlnyb/agd91eMHTBDez9hlNOs zv0GxiQt0Vd/KnCc7rpdkHYVRjjBaohvdZkuvz+NZnvuAjKA0uFDygYamlqt9kxHHBxT pTqVLyKPONOcA8NDJeoSLDmcwhPXO5T6IA+wnGxnECFytsyaWHE/Wbp4s985NlpI21bn ZerAPDNYdaMFg2MldmwZJG2Kp3QA7g8wmgJGeJqVBlasSRM7eDyv7mm8PTyh9ZVLxjYN Yj9RQVVXBa2wWqY/UHkwLyGR0APrMuRN/Bs3aBlEuYMWbVtTQXfz4kkjaLTQE2Gx845x O+HQ== 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=LeNI+1yuLit3/ZWjjJEGC312MJLgqZEh0xA2ccRhqdU=; b=iOt+gU9eGs/jilMC0x63KqMqSEli8QsawbmnTu+K6ErDCOTtMXlts6Rg9+2NioIlrR MNyrJdvCTU5VEE9Wpk9QXbtPy0pSGjt3a8UCpeScADZOuQOpEgunXw4CtUCmqc/WBaZi pX50pW9ovEZakUlGLef7WsxyrfZv4bpWX8U7X/vnlyF4mhVIeE8bU5U9wLX8qnrHJjhw RZvC5IQxVuVOYXCJdq6+KdJImDnLqnpQ4Z/36mvhSxF3qJlhzcV2iOgSxNqlnsOuB/Yg swYWWCwolhIH7o9scO1Fs+9xSPrQJwGpPv77XLn1LqswJ4Geoog4fZDkdFIy2pOEm6CL djyA== X-Gm-Message-State: AOAM533ymLXhH8pnkmWhQnKb+66HfveTKDVZXvrO4D2lGSIs+msrhkKV Cxtr14/XV6wpu4WnR6ASj+8I4/Gi9YdI6FJpHnT9Aw== X-Google-Smtp-Source: ABdhPJxJJGQnMuwUdtw6GoJjHj04m1NXopWdO2wERsaMjPU/S8+dPvk0tJ0FegD7Ya18k2Qk6VdYtKi/agjHOGNkGpE= X-Received: by 2002:a37:5842:: with SMTP id m63mr17034695qkb.347.1592249427887; Mon, 15 Jun 2020 12:30:27 -0700 (PDT) MIME-Version: 1.0 References: <4425D473-7A6A-4AF5-BA53-635255D6EC55@nostrum.com> In-Reply-To: From: Richard Barnes Date: Mon, 15 Jun 2020 15:30:12 -0400 Message-ID: To: Emad Omara Cc: Ben Campbell , Sergio murillo , Alexandre GOUAILLARD , Patrick McManus , Dispatch WG , sframe@ietf.org Content-Type: multipart/alternative; boundary="0000000000008b1cfe05a82475ee" Archived-At: Subject: Re: [Sframe] Dispatch of SFrame for End-To-End Encrypted Conference Calls 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, 15 Jun 2020 19:30:31 -0000 --0000000000008b1cfe05a82475ee Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Mon, Jun 15, 2020 at 3:20 PM Emad Omara wrote: > Thanks. > > Some responses inline. Other authors please feel free to add more. > > Emad > > On Mon, Jun 15, 2020 at 12:13 PM Ben Campbell wrote: > >> Thanks, Patrick. >> >> Authors: It would be helpful to get a little more background: >> >> - How does this work relate to PERC? What problem does it solve that PER= C >> doesn=E2=80=99t? >> > This is a completely different approach than PERC. THis draft aims for > simplicity and efficiency. The sdrame draft itself has some benchmarks > against the PERC approach. That being said the sframe draft focuses main= ly > on the media encryption part and touches slightly other parts in the syst= em > like key management and integration with WebRTC. If this became a standar= d > we will have to write a separate draft for each of these two topics. > >> - Do you expect this to become an IETF standard available to anyone to >> implement? Who do you think would implement it? >> > Yes. This will be implemented by the video conference providers. The cor= e > protocol implementation is on the client side. > >> - Is anyone outside of Google working on the spec or implementing the >> protocol? Has anyone outside of Google expressed interest in doing so? >> > Yes, the document is co-authored by +Sergio murillo > & +Alexandre GOUAILLARD > from Cosmos Software. > On this last point: We are considering this for some projects at Cisco. --Richard > - Anything else you think would help motivate people to read the draft an= d >> give feedback :-) >> >> Thanks! >> >> Ben. >> >> On Jun 15, 2020, at 2:05 PM, Patrick McManus >> wrote: >> >> Hi All - >> >> I failed to note the link highlighting in Emad's mail to the list which >> already contained the draft. Sorry about that. (It's >> https://tools.ietf.org/html/draft-omara-sframe-00 if you too missed it). >> >> There's also a github and mailing list referenced: >> https://github.com/eomara/sframe >> https://mailarchive.ietf.org/arch/browse/sframe/? >> >> [I've also forked the Subject Line to help interested readers] >> >> On Mon, Jun 15, 2020 at 2:42 PM Patrick McManus < >> patrick.ducksong@gmail.com> wrote: >> >>> Sounds really interesting Emad and there's obviously related work going >>> on (at least perc, maybe even mls..). >>> >>> Sending that email Ben mentions to the dispatch list to raise awareness >>> with a link to the draft would be helpful in getting the process starte= d.. >>> >>> On Mon, Jun 15, 2020 at 2:33 PM Emad Omara wrote= : >>> >>>> Hi Ben, >>>> >>>> This draft proposes a solution for end-to-end encrypted conference >>>> calls. We implemented this in Google a couple of years ago in Duo, but= the >>>> draft was only published last month given the current interest in the = topic. >>>> >>>> The goal of the session is to go through the proposal and see if there >>>> is interest to continue working on this, and if so what will be the be= st WG >>>> to host this work. >>>> >>>> Thanks >>>> Emad >>>> >>>> On Mon, Jun 15, 2020 at 11:02 AM Ben Campbell wrote: >>>> >>>>> Hi Emad, >>>>> >>>>> We prioritize DISPATCH meeting time to focus on topics that have had >>>>> DISPATCH list discussion and need high-bandwidth time to resolve. Unl= ess >>>>> I=E2=80=99ve missed something, this topic has not previously come up = in DISPATCH. I >>>>> suggest sending a note to this list with some background about the dr= aft >>>>> and how you would like to see it progress. >>>>> >>>>> Thanks! >>>>> >>>>> Ben. >>>>> >>>>> On Jun 15, 2020, at 12:32 PM, Emad Omara < >>>>> emadomara=3D40google.com@dmarc.ietf.org> wrote: >>>>> >>>>> Hi, >>>>> >>>>> We would like to have a session in the next IETF to discuss the SFram= e >>>>> draft Can you >>>>> please help scheduling this? >>>>> >>>>> Thanks >>>>> Emad >>>>> _______________________________________________ >>>>> dispatch mailing list >>>>> dispatch@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/dispatch >>>>> >>>>> >>>>> >> -- > Sframe mailing list > Sframe@ietf.org > https://www.ietf.org/mailman/listinfo/sframe > --0000000000008b1cfe05a82475ee Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Mon, Jun 15, 2020 at 3:20 PM Emad = Omara <emadomara=3D40goog= le.com@dmarc.ietf.org> wrote:
Thanks.

Some= responses inline. Other authors please feel free to add more.

Emad

On Mon, Jun 15, 2020 at 12:13 PM Ben Campbell <ben@nostrum.com> wrote= :
Thanks, P= atrick.

Authors: It would be helpful to get a little mor= e background:=C2=A0

- How does this work relate to= PERC? What problem does it solve that PERC doesn=E2=80=99t?
This is a completely different approach than PERC. THis draf= t aims for simplicity and efficiency. The sdrame draft itself has some benc= hmarks against the PERC approach.=C2=A0 That being said the sframe draft fo= cuses mainly on the media encryption part and touches slightly other parts = in the system like key management and integration with WebRTC. If this beca= me a standard we will have to write a separate=C2=A0draft for each of these= two topics.=C2=A0
<= div>
- Do you expect this to become an IETF standard available to anyon= e to implement? Who do you think would implement it?=C2=A0
Yes. This will be implemented=C2=A0by the=C2=A0 video conferen= ce providers. The core protocol implementation is on the client side.
=
- Is anyone out= side of Google working on the spec or implementing the protocol? Has anyone= outside of Google expressed interest in doing so?
=
Yes, the document is co-authored by=C2=A0+Sergio murillo=C2=A0&a= mp;=C2=A0+Alexandre GOUAILLARD=C2=A0from Cosmos Software.=C2=A0
=

On this last point: We are con= sidering this for some projects at Cisco.

--Richar= d

=C2=A0
- Anything else you thi= nk would help motivate people to read the draft and give feedback :-)
=

Thanks!

Ben.

On Jun 15, 2020, at 2:05 PM, Pa= trick McManus <patrick.ducksong@gmail.com> wrote:

Hi All -

I failed to note the link highlightin= g in Emad's mail to the list which already contained the draft. Sorry a= bout that. (It's=C2=A0https://tools.ietf.org/html/draft-omara-sfra= me-00=C2=A0if you too missed it).

There's also a github and = mailing list referenced:
https://github.com/eomara/sframe
https://mailar= chive.ietf.org/arch/browse/sframe/?

[I've al= so forked the Subject Line to help interested readers]

On Mon, Jun 15,= 2020 at 2:42 PM Patrick McManus <patrick.ducksong@gmail.com> wrote:
Sounds= really interesting Emad and there's obviously related=C2=A0work going = on (at least perc, maybe even mls..).

Sending that email= Ben mentions to the dispatch list to raise awareness with a link to the dr= aft would be helpful in getting the process started..

On Mon, Jun 15, = 2020 at 2:33 PM Emad Omara <emadomara@google.com> wrote:
Hi Ben,

This draft proposes a solution for end-to-end encrypted conference calls= . We implemented=C2=A0this in Google a couple of years ago in Duo, but the = draft was only published last month given the current interest in the topic= .

The goal of the session is to go through the pro= posal and see if there is interest to continue working on this, and if so w= hat will be the best WG to host this work.=C2=A0

T= hanks
Emad

On Mon, Jun 15, 2020 at 11:02 AM Ben Campbell <= ;ben@nostrum.com&g= t; wrote:
H= i Emad,

We prioritize DISPATCH meeting time to focus on = topics that have had DISPATCH list discussion and need high-bandwidth time = to resolve. Unless I=E2=80=99ve missed something, this topic has not previo= usly come up in DISPATCH. I suggest sending a note to this list with some b= ackground about the draft and how you would like to see it progress.
<= div>
Thanks!

Ben.

On Jun 15, 2020, at 12:32 PM, Emad Omara <ema= domara=3D40google.com@dmarc.ietf.org> wrote:

Hi,

We would like to have a session in the next= IETF to discuss the SFrame draft=C2=A0Can you please help schedul= ing this?

Thanks
Emad
_______________________________________________
dispatch mailing listdispatch@ietf.org
https://www.ietf.org/mailman/listinfo/dispatch


--
Sframe mailing list
Sframe@ietf.org https://www.ietf.org/mailman/listinfo/sframe
--0000000000008b1cfe05a82475ee-- From nobody Mon Jun 15 13:11:46 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 90AEC3A087D for ; Mon, 15 Jun 2020 13:11:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, 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 ZmWEEH8YosUn for ; Mon, 15 Jun 2020 13:11:32 -0700 (PDT) Received: from mail-wr1-x42f.google.com (mail-wr1-x42f.google.com [IPv6:2a00:1450:4864:20::42f]) (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 CA56C3A08E4 for ; Mon, 15 Jun 2020 13:10:03 -0700 (PDT) Received: by mail-wr1-x42f.google.com with SMTP id l11so18456470wru.0 for ; Mon, 15 Jun 2020 13:10:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cosmosoftware-io.20150623.gappssmtp.com; s=20150623; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-transfer-encoding:content-language; bh=N+0bWbgFl7wjkNbYvvLQ5a9yh/8h6SSIDATYvDroqqM=; b=mGM0SN35ZjAvW5NPPVrRwW0EHjOpZLwbnHVDkJ2s5+nKH4aDfGdjsslMqDmHD5VdgQ 4fTeALxoBlvKnv0ToaU60521GDurbemyaYBpVAXEVPFd0JRKql9PgcBJLuN4qZ3f6tBv 2BDbVPw5nBAB8pKahPV0lQg7eDYBzQwjfOwP26MhWj5Q5xABds7ZkndymjhZaHD6M1sq UnxcJgSM2l5RuC4l9OAo8XPLBjsmcwtw+oaV2rL3G5jg8Mo/HCTD+JZ4wkkx+LpBLjNJ XBgFdVdcd5GcWsFM6gCjRlIsKFImDOfGZm7EFiYYx3aMvS4qtlhJwVtJmGL4jgdJmc+e xETQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding :content-language; bh=N+0bWbgFl7wjkNbYvvLQ5a9yh/8h6SSIDATYvDroqqM=; b=QJrjJERaS6XT1B6YY1M2Lx9PgJyO1DZZ9g3f+tB7bc5ZGDw7jbzfanXbICwcvjwDxz kcv9OqRUyGiu9Og8NA8k9wJzrCEVyG7aiR7Iz7tpGQ5OYM7AJz6UGXP164XZm6a3wsuB mtP6eHSiL6ZnPNX3o+O+l9hqeuKi0Dxtrp7yy3humysf/veQtof5fVD5Uygp9mp3BjdP wOzjMEIlhThembvARqESvpfzKPBaMyCitAdOOH+yELY9vh9tA1jlNZp1r4gH4ZOdTfEN 0y7mJCepv/7xDfnW6DH4nyA6I0LGp9pBZ5fF9Tk1gA+0AuFCeXij4R9jiq+0Oh88BLFa FkRw== X-Gm-Message-State: AOAM532RQ1GETcqagcgbP8PfvqR7X1cdBjsuN7od32hKbE6fg2azwPb9 SCcyxTzn2bo0mvCSn/42z4/MmuGnpfc= X-Google-Smtp-Source: ABdhPJwtTOEYJa3e6g0TMIUIe+hTRTh260PnbsF9wTE3LguKoRZt0nQutfWs/S+zudi3OMM5ZnaZVA== X-Received: by 2002:a5d:4e87:: with SMTP id e7mr29033569wru.427.1592251801612; Mon, 15 Jun 2020 13:10:01 -0700 (PDT) Received: from [192.168.0.11] (79.108.125.160.dyn.user.ono.com. [79.108.125.160]) by smtp.gmail.com with ESMTPSA id a6sm25455581wrn.38.2020.06.15.13.10.00 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 15 Jun 2020 13:10:01 -0700 (PDT) To: Dispatch WG , sframe@ietf.org References: <4425D473-7A6A-4AF5-BA53-635255D6EC55@nostrum.com> From: Sergio Garcia Murillo Message-ID: Date: Mon, 15 Jun 2020 22:10:03 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.9.0 MIME-Version: 1.0 In-Reply-To: <4425D473-7A6A-4AF5-BA53-635255D6EC55@nostrum.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US Archived-At: Subject: Re: [Sframe] Dispatch of SFrame for End-To-End Encrypted Conference Calls 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, 15 Jun 2020 20:11:34 -0000 On 15/06/2020 21:13, Ben Campbell wrote: > - Do you expect this to become an IETF standard available to anyone to > implement? Who do you think would implement it? > - Is anyone outside of Google working on the spec or implementing the > protocol? Has anyone outside of Google expressed interest in doing so? Cosmo has co-authored the spec and we have released an open source pure javascript implementation based on webcrypto (https://github.com/medooze/sframe) and using with w3c insertable streams (https://github.com/w3c/webrtc-insertable-streams) It is already integrated in Medooze products: https://medium.com/@medooze/sframe-js-end-to-end-encryption-for-webrtc-f9a83a997d6d And in Janus: https://www.meetecho.com/blog/janus-e2ee-sframe/ Best regards Sergio From nobody Mon Jun 15 13:13: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 E36023A0999; Mon, 15 Jun 2020 13:13:19 -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 qiKnF-_kyxvM; Mon, 15 Jun 2020 13:13:14 -0700 (PDT) Received: from mail-wm1-x331.google.com (mail-wm1-x331.google.com [IPv6:2a00:1450:4864:20::331]) (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 31F1D3A0985; Mon, 15 Jun 2020 13:13:02 -0700 (PDT) Received: by mail-wm1-x331.google.com with SMTP id l26so798014wme.3; Mon, 15 Jun 2020 13:13:02 -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-language; bh=ojtXvp9gp2tUZp2czMuWbXwG4Esmq4fvjvV4BClrv5g=; b=GY07vcS5Fo2cRHj+D1ddG0NNiAhn8++La8n/a2D8Q9tGVvnwK7HakC+DLbQt68CvYu 0eXMulr20cUvV46hRtfe8bWopWDCd1SylmWSfacPseiC9sgPjrC2kji8c0x4l9kfnUGa UYC/ZNc/ZMVi2vQDbKqRhDEMdTEAYU7bBvdzgdya6n0e3qlsgEHObZni9l6ya84m4n1/ 4KHFBNLgOAT9S7UxtYSDY1VpZ3g96WJkSWJLpqVVBTiDxtFYOs6EMap6q3vERjZvLss4 dsBeb2SGVePnLa/etCj4LIlMUVicuYj8PRvO6GoBocz7KLCXKTdJxDu0pR6CHulvkb2e HTNg== 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-language; bh=ojtXvp9gp2tUZp2czMuWbXwG4Esmq4fvjvV4BClrv5g=; b=N9gmGD8zatzTVdMGL7q3NGNuUym5WSCEUslq+B/ySswztKdIk1BceRT2WDyzU+dks+ LHH32n7T38K24lLnAOB8zCkTJax8SanKBHpiE1IDOUCbq0n92DYX2RDaqmIr0vxSCQyY nmMIkPvPg+42eGTq0LIPmYoor83EijdevFFkzNU+lOxbZOWK9+Bn/3sAc/9wxL7P7Xjf WE+NWCEph3nBzToMDv9ZueLz4qOxHoZGt7q7Sp++thgU0JqWk7HBEITFzYwap3mg4XmF JKMgpdRrtvPQly6yPF2vrxs0cYo3NXdOkqmqxBhyl1wBdIxbMxC0gNjFwcGTw2ypXv77 Dx/g== X-Gm-Message-State: AOAM530bvsGMTjyPdkqTDLT5m3BoWzxso6ODyGEgdROH7BHeUsEvH8YZ 9w6F+WgTIwxre53dPdC91Ak/ikci8Yo= X-Google-Smtp-Source: ABdhPJy8yWh0GOaCNivkEO2EtbqBmKoZbwMtQVeBF3qNC5og0rplPKYq+dQ1Yh89pMs+RGbPKp7Ydw== X-Received: by 2002:a05:600c:4152:: with SMTP id h18mr1014270wmm.189.1592251979321; Mon, 15 Jun 2020 13:12:59 -0700 (PDT) Received: from [192.168.0.11] (79.108.125.160.dyn.user.ono.com. [79.108.125.160]) by smtp.googlemail.com with ESMTPSA id b185sm1498554wmd.3.2020.06.15.13.12.58 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 15 Jun 2020 13:12:58 -0700 (PDT) To: Ben Campbell , Patrick McManus Cc: Dispatch WG , Emad Omara , sframe@ietf.org References: <4425D473-7A6A-4AF5-BA53-635255D6EC55@nostrum.com> From: Sergio Garcia Murillo Message-ID: Date: Mon, 15 Jun 2020 22:13:00 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.9.0 MIME-Version: 1.0 In-Reply-To: <4425D473-7A6A-4AF5-BA53-635255D6EC55@nostrum.com> Content-Type: multipart/alternative; boundary="------------4034487050AB7305F7FC3CD3" Content-Language: en-US Archived-At: Subject: Re: [Sframe] [dispatch] Dispatch of SFrame for End-To-End Encrypted Conference Calls 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, 15 Jun 2020 20:13:20 -0000 This is a multi-part message in MIME format. --------------4034487050AB7305F7FC3CD3 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit On 15/06/2020 21:13, Ben Campbell wrote: > - Do you expect this to become an IETF standard available to anyone to > implement? Who do you think would implement it? > - Is anyone outside of Google working on the spec or implementing the > protocol? Has anyone outside of Google expressed interest in doing so? Cosmo has co-authored the spec and we have released an open source pure javascript implementation based on webcrypto (https://github.com/medooze/sframe) and using with w3c insertable streams (https://github.com/w3c/webrtc-insertable-streams) It is already integrated in Medooze products: https://medium.com/@medooze/sframe-js-end-to-end-encryption-for-webrtc-f9a83a997d6d And in Janus: https://www.meetecho.com/blog/janus-e2ee-sframe/ Best regards Sergio --------------4034487050AB7305F7FC3CD3 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit
On 15/06/2020 21:13, Ben Campbell wrote:
- Do you expect this to become an IETF standard available to anyone to implement? Who do you think would implement it?
- Is anyone outside of Google working on the spec or implementing the protocol? Has anyone outside of Google expressed interest in doing so?

Cosmo has co-authored the spec and we have released an open source pure javascript implementation based on webcrypto (https://github.com/medooze/sframe) and using with w3c insertable streams (https://github.com/w3c/webrtc-insertable-streams)

It is already integrated in Medooze products:

https://medium.com/@medooze/sframe-js-end-to-end-encryption-for-webrtc-f9a83a997d6d

And in Janus:

https://www.meetecho.com/blog/janus-e2ee-sframe/


Best regards

Sergio
--------------4034487050AB7305F7FC3CD3-- From nobody Mon Jun 15 13:21:50 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 EE5173A0DDC for ; Mon, 15 Jun 2020 13:21:47 -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=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 Cp2_7A87yrbw for ; Mon, 15 Jun 2020 13:21:40 -0700 (PDT) Received: from mail-ot1-x331.google.com (mail-ot1-x331.google.com [IPv6:2607:f8b0:4864:20::331]) (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 457243A0C8B for ; Mon, 15 Jun 2020 13:21:34 -0700 (PDT) Received: by mail-ot1-x331.google.com with SMTP id 97so14177595otg.3 for ; Mon, 15 Jun 2020 13:21:34 -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=dc0FiEAGsa+M6f8l6fn/fgt01MGnlCUXqt5yDoKd+3M=; b=eHJZ9yT13U3Xo5I6nETVv+qLUY/kK77wMFp+RZYDscoEf4W2v9bPUcyTfYueXIBFfT QxJgCQ1iTASCAdn5ZLD5zXz39vdBWtxDhUrwsorVLzjzt2O0u25UPDM+TsxVvS74v3cw X2xWj7Sg6RlivtIZjqxMXU5EdDHm2ckrnTQQ95QrLAM/v/C2P7wqBgCuJUxffx+IIoOR kTK25qtAphFDIgrBLv1btM1Vy6HkrGSWOXxagtzsuPqWfHMx+N1DWHxfoMHgXffACKF3 GflK3YAS0fpwZcSDOHc5mXuJLumqg4GHFShogBn7KuQ/FdHt/aejC6754GbSGNejCqcF vvyg== 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=dc0FiEAGsa+M6f8l6fn/fgt01MGnlCUXqt5yDoKd+3M=; b=ZDdWPm3y4FD05DyMXFMYtbHLu5o+WxA5I0Dxf1lZSE23lycZ3zMQQQPnfOXdKEbSuc gamXGC6iBuIYACvnv+MyivpdV2BIbTuZ2gpx7ug6mmf6Kt58HoxyLFT+jynel7lQMDWg CgcQSBvWJ5Zz+W0QZ3vwsUFyjl30EVrSKckTtJ9EfrQXfTa//pXU/PuE+NclfiJJWten /ZrAFmPPNz6l+EkZH1WNrld0sppq97UiMlEvhTDBUITQIrXsMxYZmsEU0VnXygZHLKNK ApyoszpvMRqEfw1fgOGDlYYn6V4EnHrfd/H0yUnEGN3XIhw+0PNkM5SPrp/7Zolevo/j XwGg== X-Gm-Message-State: AOAM5324bHpTh51HC3+OQTCI8GT8DKW3yRrtHnLbtnxEUuEudPwa1nG6 r6yUZK1yz4khFBEgiI2D94gELnc6/cseCGGwDPOMTw== X-Google-Smtp-Source: ABdhPJzm0FHJuJqDEYk1TPW2v9pnHS9CQn6E8ku5gS6ZxryB+DBnu+wH7kYOWzOa+RINxLXJ1dOOzcCoss+B/667VoQ= X-Received: by 2002:a9d:3f37:: with SMTP id m52mr24573281otc.255.1592252493171; Mon, 15 Jun 2020 13:21:33 -0700 (PDT) MIME-Version: 1.0 References: <4425D473-7A6A-4AF5-BA53-635255D6EC55@nostrum.com> In-Reply-To: From: Alexandre GOUAILLARD Date: Mon, 15 Jun 2020 22:21:22 +0200 Message-ID: To: Sergio Garcia Murillo Cc: Ben Campbell , Patrick McManus , Emad Omara , Dispatch WG , sframe@ietf.org Content-Type: multipart/alternative; boundary="0000000000003fa0c205a8252c70" Archived-At: Subject: Re: [Sframe] [dispatch] Dispatch of SFrame for End-To-End Encrypted Conference Calls 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, 15 Jun 2020 20:21:50 -0000 --0000000000003fa0c205a8252c70 Content-Type: text/plain; charset="UTF-8" With respect to PERC, SFrame is media transport agnostic, and would work with QUIC, while PERC is Rtp-Based only.Conferencing only, and assume e.g. SRTP. On Mon, Jun 15, 2020 at 10:13 PM Sergio Garcia Murillo < sergio.garcia.murillo@gmail.com> wrote: > > On 15/06/2020 21:13, Ben Campbell wrote: > > - Do you expect this to become an IETF standard available to anyone to > implement? Who do you think would implement it? > - Is anyone outside of Google working on the spec or implementing the > protocol? Has anyone outside of Google expressed interest in doing so? > > > Cosmo has co-authored the spec and we have released an open source pure > javascript implementation based on webcrypto ( > https://github.com/medooze/sframe) and using with w3c insertable streams ( > https://github.com/w3c/webrtc-insertable-streams) > > It is already integrated in Medooze products: > > > https://medium.com/@medooze/sframe-js-end-to-end-encryption-for-webrtc-f9a83a997d6d > > And in Janus: > > https://www.meetecho.com/blog/janus-e2ee-sframe/ > > > Best regards > > Sergio > -- > Sframe mailing list > Sframe@ietf.org > https://www.ietf.org/mailman/listinfo/sframe > --0000000000003fa0c205a8252c70 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
With respect to PERC,
SFrame is media transport agnost= ic, and would work with=C2=A0QUIC, while PERC is Rtp-Based only.Conferencin= g only, and assume e.g. SRTP.

On Mon, Jun 15, 2020 at 10:13 PM Sergio = Garcia Murillo <sergi= o.garcia.murillo@gmail.com> wrote:
=20 =20 =20

On 15/06/2020 21:13, Ben Campbell wrote:
- Do you expect th= is to become an IETF standard available to anyone to implement? Who do you think would implement it?
- Is anyone outside of Google working on the spec or implementing the protocol? Has anyone outside of Google expressed interest in doing so?

Cosmo has co-authored the spec and we have released an open source pure javascript implementation based on webcrypto (https://github.com/medooze/sfra= me) and using with w3c insertable streams (https://github.com/w3c/webrt= c-insertable-streams)

It is already integrated in Medooze products:

https://medium.com/@medooze/sfra= me-js-end-to-end-encryption-for-webrtc-f9a83a997d6d

And in Janus:

https://www.meetecho.com/blog/janus-e2ee-sframe/


Best regards

Sergio
--
Sframe mailing list
Sframe@ietf.org https://www.ietf.org/mailman/listinfo/sframe
--0000000000003fa0c205a8252c70-- From nobody Fri Jun 26 01:18:05 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 36EE33A11E7; Fri, 26 Jun 2020 01:18:00 -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 oDSyfv5eM7IR; Fri, 26 Jun 2020 01:17:58 -0700 (PDT) Received: from mail-wm1-x344.google.com (mail-wm1-x344.google.com [IPv6:2a00:1450:4864:20::344]) (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 0D2E53A11E5; Fri, 26 Jun 2020 01:17:58 -0700 (PDT) Received: by mail-wm1-x344.google.com with SMTP id 22so7986239wmg.1; Fri, 26 Jun 2020 01:17:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-language:thread-index; bh=ejA36kwyyKDA5CQeNHVvIwfcfNCHK2A3qlZGlH62xuE=; b=rSbkZMN2q+6xCKLSAm5APx6fQvhwkvqcUyio578CjQbZM3MKJTpCzuwYHF4aLyIqhz qicuxD/Trfy9DD4f9U915Vg9UuKPJywuoI/CaqWAh8tr+0hsbWmlnLQ3Ut6lBOxjiQvK hMDqgXCwZ8fJkzf6AO4Ewcq6SLlYTbh4TNWbsenrwMNVabBux+ViboZcbMqQJ9Uu4Yg6 q7nGCMsEsxIWR3dLgZX7ZN108UyGWreJD4ix6/CkP8DVS5/g7j8KLfZ/8fwj49m4gwoI NoPxnyIeUPZA2H74V+hh6mAljL7BA9K9KL6f5A7vwhogpm1bj0LM7vaal3KAXj4TgJpV 7bUQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:references:in-reply-to:subject:date :message-id:mime-version:content-language:thread-index; bh=ejA36kwyyKDA5CQeNHVvIwfcfNCHK2A3qlZGlH62xuE=; b=Fqp/6ZwOM89ysxhH3K81gKdt25NQHLUOrQVXT55J1h2RTbaVrSX8v2FquQSEXrikTp JBIfnyoku+vQz0UJOqVG80mRqPt8qZHL9CQfQP2qNiQ3hF84ElYDS0pRyi6QvWzBAoah 4UiVfaETVG3/YWoqCfxXB491wCYUHIZcozF1Y1x/jNh/t/FqWL5TFcJUdMUOWVDLDCVO QM/0i5jc+hfANQC4ImgsAoK/IjHDwKr/pDDdyehm9IHYTLH4csSKAR5jlIF3O9eWwpEw 5upLHBOKf27HCfiqSED7FFvn7OUrLZ9lXIeyKzE4t99HqLt8uC/EBDGUEUibMfmqPx0N bBDw== X-Gm-Message-State: AOAM530sKRY57t2xAyH7Axp3qNU/FGnl/qYfR9uy7xN1j9nLk8VLWdQD Vv1AYCneoF6MNJHO2oB6QEoAZGbz X-Google-Smtp-Source: ABdhPJxm0Y3jGON/FnVmDe/GNXdK4/d4BN2hobAlspfTOrjIudjyQfkIzelEk2v527f+cJr3ZLoOqQ== X-Received: by 2002:a1c:7d54:: with SMTP id y81mr2206571wmc.110.1593159476459; Fri, 26 Jun 2020 01:17:56 -0700 (PDT) Received: from RoniPC (bzq-79-180-107-12.red.bezeqint.net. [79.180.107.12]) by smtp.gmail.com with ESMTPSA id h12sm15522218wmm.42.2020.06.26.01.17.54 (version=TLS1 cipher=ECDHE-ECDSA-AES128-SHA bits=128/128); Fri, 26 Jun 2020 01:17:55 -0700 (PDT) From: "Roni Even" To: "'Patrick McManus'" , "'Emad Omara'" Cc: "'Ben Campbell'" , "'Dispatch WG'" , References: In-Reply-To: Date: Fri, 26 Jun 2020 11:17:51 +0300 Message-ID: <0e4d01d64b92$49cf5040$dd6df0c0$@gmail.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0E4E_01D64BAB.6F1DC0C0" X-Mailer: Microsoft Outlook 14.0 Content-Language: he Thread-Index: AQH9xWGrhZcH8B5JF584hFypOrcytwNgTgg2AiD2rEYCDEUinwIlhVpuqE4AxRA= Archived-At: Subject: Re: [Sframe] [dispatch] Dispatch of SFrame for End-To-End Encrypted Conference Calls 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: Fri, 26 Jun 2020 08:18:00 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0E4E_01D64BAB.6F1DC0C0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Hi, =20 I find this proposal interesting since the issue of key distribution in = multipoint conferences is a problem even if the media mixer (any = topology) is a trusted entity and wants to distribute the encrypted = media without doing decrypt/encrypt cycle. One point to look at is that = in the past when we designed RFC5764 (DTLS/SRTP) the consensus was that = key exchange must be done in-band.=20 As far as I remember one of the motivation point for EKT in AVT was to = address the key distribution for multipoint conferences.=20 =20 As for the work, if there is a consensus to accept this work, it will = require support for RTP. How to signal that this is such a payload and = what should be the RTP PT in the RTP header. (how to negotiate what is = the secure payload inside the SFRAME) On one hand it may look like a new RTP payload (similar to MPEG2 RTP = payload (RFC2250)) and as such is in scope for AVTCore but as for the = framework I think this is not AVTCore work. =20 Roni Even AVTCore co-chair =20 =20 =20 From: dispatch [mailto:dispatch-bounces@ietf.org] On Behalf Of Patrick = McManus Sent: Monday, June 15, 2020 10:06 PM To: Emad Omara Cc: Ben Campbell; Dispatch WG; sframe@ietf.org Subject: [dispatch] Dispatch of SFrame for End-To-End Encrypted = Conference Calls =20 Hi All - I failed to note the link highlighting in Emad's mail to the list which = already contained the draft. Sorry about that. (It's = https://tools.ietf.org/html/draft-omara-sframe-00 if you too missed it). There's also a github and mailing list referenced: https://github.com/eomara/sframe https://mailarchive.ietf.org/arch/browse/sframe/? =20 [I've also forked the Subject Line to help interested readers] =20 On Mon, Jun 15, 2020 at 2:42 PM Patrick McManus = wrote: Sounds really interesting Emad and there's obviously related work going = on (at least perc, maybe even mls..). =20 Sending that email Ben mentions to the dispatch list to raise awareness = with a link to the draft would be helpful in getting the process = started.. =20 On Mon, Jun 15, 2020 at 2:33 PM Emad Omara wrote: Hi Ben, =20 This draft proposes a solution for end-to-end encrypted conference = calls. We implemented this in Google a couple of years ago in Duo, but = the draft was only published last month given the current interest in = the topic. =20 The goal of the session is to go through the proposal and see if there = is interest to continue working on this, and if so what will be the best = WG to host this work.=20 =20 Thanks Emad =20 On Mon, Jun 15, 2020 at 11:02 AM Ben Campbell wrote: Hi Emad, =20 We prioritize DISPATCH meeting time to focus on topics that have had = DISPATCH list discussion and need high-bandwidth time to resolve. Unless = I=E2=80=99ve missed something, this topic has not previously come up in = DISPATCH. I suggest sending a note to this list with some background = about the draft and how you would like to see it progress. =20 Thanks! =20 Ben. On Jun 15, 2020, at 12:32 PM, Emad Omara = wrote: =20 Hi, =20 We would like to have a session in the next IETF to discuss the SFrame = draft Can you = please help scheduling this? =20 Thanks Emad _______________________________________________ dispatch mailing list dispatch@ietf.org https://www.ietf.org/mailman/listinfo/dispatch =20 ------=_NextPart_000_0E4E_01D64BAB.6F1DC0C0 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

Hi,

 

I find this proposal interesting since the issue of key distribution = in multipoint conferences is a problem even if the media mixer (any = topology) is a trusted entity and wants to distribute the encrypted = media without doing decrypt/encrypt cycle.  One point to look at is = that in the past when we designed RFC5764 (DTLS/SRTP) the consensus was = that key exchange must be done in-band.

As far as I remember one of the motivation point for EKT in AVT was = to address the key distribution for multipoint conferences. =

 

As for the work, if there is a consensus to accept this work, it will = require support for RTP. How to signal that this is such a payload and = what should be the RTP PT in the RTP header. (how to negotiate what is = the secure payload inside the SFRAME)

On one hand it may look like a new RTP payload (similar to MPEG2 RTP = payload (RFC2250)) and as such is in scope for AVTCore but as for the = framework I think this is not AVTCore work.

 

Roni Even

AVTCore co-chair

 

 

 

From:= = dispatch [mailto:dispatch-bounces@ietf.org] On Behalf Of Patrick = McManus
Sent: Monday, June 15, 2020 10:06 PM
To: = Emad Omara
Cc: Ben Campbell; Dispatch WG; = sframe@ietf.org
Subject: [dispatch] Dispatch of SFrame for = End-To-End Encrypted Conference = Calls

 

Hi = All -

I failed to note the link highlighting in Emad's mail to = the list which already contained the draft. Sorry about that. = (It's https://tools.= ietf.org/html/draft-omara-sframe-00 if you too missed = it).

There's also a github and mailing list referenced:
https://github.com/eomara/sfram= e
https://mailar= chive.ietf.org/arch/browse/sframe/?

 

[I've also forked the Subject Line to help interested = readers]

 

On = Mon, Jun 15, 2020 at 2:42 PM Patrick McManus <patrick.ducksong@gmail.com= > wrote:

Sounds really interesting Emad and there's obviously = related work going on (at least perc, maybe even = mls..).

 

Sending that email Ben mentions to the dispatch list = to raise awareness with a link to the draft would be helpful in getting = the process started..

 

On = Mon, Jun 15, 2020 at 2:33 PM Emad Omara <emadomara@google.com> = wrote:

Hi = Ben,

 

This draft proposes a solution for end-to-end = encrypted conference calls. We implemented this in Google a couple = of years ago in Duo, but the draft was only published last month given = the current interest in the topic.

 

The goal of the session is to go through the proposal = and see if there is interest to continue working on this, and if so what = will be the best WG to host this work. 

 

Thanks

Emad

 

On = Mon, Jun 15, 2020 at 11:02 AM Ben Campbell <ben@nostrum.com> = wrote:

Hi = Emad,

 

We prioritize DISPATCH meeting time to focus on topics = that have had DISPATCH list discussion and need high-bandwidth time to = resolve. Unless I=E2=80=99ve missed something, this topic has not = previously come up in DISPATCH. I suggest sending a note to this list = with some background about the draft and how you would like to see it = progress.

 

Thanks!

 

Ben.



On = Jun 15, 2020, at 12:32 PM, Emad Omara <emadomara=3D40google.com@dmarc.ietf.org> = wrote:

 

Hi,

 

We would like to have a session in the next IETF to = discuss the SFrame draft Can you please help scheduling = this?

 

Thanks

Emad

_______________________________________________
disp= atch mailing list
dispatch@ietf.org
https://www.ietf.org/mailman/listinfo/dispatch=

 

------=_NextPart_000_0E4E_01D64BAB.6F1DC0C0-- From nobody Fri Jun 26 04:05:34 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 B994F3A0B30 for ; Fri, 26 Jun 2020 04:05:32 -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 Ol9mWLX3XoXU for ; Fri, 26 Jun 2020 04:05:31 -0700 (PDT) Received: from mail-ot1-x329.google.com (mail-ot1-x329.google.com [IPv6:2607:f8b0:4864:20::329]) (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 F38D13A1228 for ; Fri, 26 Jun 2020 04:05:30 -0700 (PDT) Received: by mail-ot1-x329.google.com with SMTP id n24so5978981otr.13 for ; Fri, 26 Jun 2020 04:05:30 -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=CgH5sOaS1TmobupByT6mIWRGVrweS/5r4u0AwlA4mH4=; b=NPL23DxBN7YSE3whtgifrAzolyXCLQd0xEpJFdFq93Ek3R7o0zI6kTe1t/dUb7Eot9 TpGTKpaetpwxQWwiNNuNR1i8pTcj0Zh/TdcgHB69V7S0SBiHGZRGLCsnS4sxECh0yFof kgqadf14c+JzzNlVBEu1Ym2mtr5MucaNY5nbI9TMPVEnfdui4OASEGhPxJG8emroeUjS 3Xnwaak3Vr32MJ4XNVHjJM1TDO4+3jYVsG76V2y8TyKztarluW90ytZKQNa7NN5h4s+y av3qmX387ZLSisbh545rs5676XEsCk+tduKq8tqXnBgt4KMp8wj6Q+1+q+znneqZ8c1F mMXg== 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=CgH5sOaS1TmobupByT6mIWRGVrweS/5r4u0AwlA4mH4=; b=E6/xl8wFMgQKUr3IVc1G2jycNfr0NzTq5UUc9w9XyUSL6ZURUC+rgmNiOI9s2sG+VW a5jzpMisFVWtPptAI0aNRw+9i1a336lq3WedMTtpHTIViDvKs10vj5M4/ulVFWIuFz1Q AA3OePe/Vn/rPJxtRwnbrnLym9mqSbdgE7PZYJ5bKiCDrJ8g/m0dj8VvPwW7Yrk6ITP0 lr75NXV+QJypqHycSdfEDsRDx2BH8SiO4LCq82+2hmac5PP5C/G2iWYugOCegECIusU9 CXb3z4aOpF/f9uLNiQLQx2YZtvXPsWCvEAahLFidfY2WNVPQlV2TPDB6iuH3QPM27vvH ncIg== X-Gm-Message-State: AOAM530aW0TuA6mBQiksUPx1qmcaCGfy34iI+mY2zC+04ViMkrKWdcAX wmmIuXD2tWl7P9QPzs73Y3iW50x3o6Bsmov1ghh1HA== X-Google-Smtp-Source: ABdhPJxb6JimmdVnIfEr4V9hMSXPC4YH7rkuMpoVcABzfE086iOImgn6PR58qcuLkTOTA8cgiUDYsuh1Ltc1fP0+8f4= X-Received: by 2002:a05:6830:452:: with SMTP id d18mr1839186otc.164.1593169530073; Fri, 26 Jun 2020 04:05:30 -0700 (PDT) MIME-Version: 1.0 References: <0e4d01d64b92$49cf5040$dd6df0c0$@gmail.com> In-Reply-To: <0e4d01d64b92$49cf5040$dd6df0c0$@gmail.com> From: Alexandre GOUAILLARD Date: Fri, 26 Jun 2020 13:05:19 +0200 Message-ID: To: Roni Even Cc: Patrick McManus , Emad Omara , Ben Campbell , Dispatch WG , sframe@ietf.org Content-Type: multipart/alternative; boundary="000000000000e849e605a8faaf32" Archived-At: Subject: Re: [Sframe] [dispatch] Dispatch of SFrame for End-To-End Encrypted Conference Calls 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: Fri, 26 Jun 2020 11:05:33 -0000 --000000000000e849e605a8faaf32 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi roni, Those are great points. With respect to EKT, we believe that just like double and EKT were two separate matters even though there were both needed to get a complete system to work, media encryption (SFrame) and key distribution should be separated. One of the argument in favor of separation is that while media encryption will likely be the same in nature whether you do video conferencing, or streaming, or other media use cases, the trust / threat model can be vastly different, and thus require different key exchange mechanisms. With respect to RTP, and I believe emad is working on writing a draft as we speak. regards, On Fri, Jun 26, 2020 at 10:18 AM Roni Even wrote: > Hi, > > > > I find this proposal interesting since the issue of key distribution in > multipoint conferences is a problem even if the media mixer (any topology= ) > is a trusted entity and wants to distribute the encrypted media without > doing decrypt/encrypt cycle. One point to look at is that in the past wh= en > we designed RFC5764 (DTLS/SRTP) the consensus was that key exchange must = be > done in-band. > > As far as I remember one of the motivation point for EKT in AVT was to > address the key distribution for multipoint conferences. > > > > As for the work, if there is a consensus to accept this work, it will > require support for RTP. How to signal that this is such a payload and wh= at > should be the RTP PT in the RTP header. (how to negotiate what is the > secure payload inside the SFRAME) > > On one hand it may look like a new RTP payload (similar to MPEG2 RTP > payload (RFC2250)) and as such is in scope for AVTCore but as for the > framework I think this is not AVTCore work. > > > > Roni Even > > AVTCore co-chair > > > > > > > > *From:* dispatch [mailto:dispatch-bounces@ietf.org] *On Behalf Of *Patric= k > McManus > *Sent:* Monday, June 15, 2020 10:06 PM > *To:* Emad Omara > *Cc:* Ben Campbell; Dispatch WG; sframe@ietf.org > *Subject:* [dispatch] Dispatch of SFrame for End-To-End Encrypted > Conference Calls > > > > Hi All - > > I failed to note the link highlighting in Emad's mail to the list which > already contained the draft. Sorry about that. (It's > https://tools.ietf.org/html/draft-omara-sframe-00 if you too missed it). > > There's also a github and mailing list referenced: > https://github.com/eomara/sframe > https://mailarchive.ietf.org/arch/browse/sframe/? > > > > [I've also forked the Subject Line to help interested readers] > > > > On Mon, Jun 15, 2020 at 2:42 PM Patrick McManus < > patrick.ducksong@gmail.com> wrote: > > Sounds really interesting Emad and there's obviously related work going o= n > (at least perc, maybe even mls..). > > > > Sending that email Ben mentions to the dispatch list to raise awareness > with a link to the draft would be helpful in getting the process started.= . > > > > On Mon, Jun 15, 2020 at 2:33 PM Emad Omara wrote: > > Hi Ben, > > > > This draft proposes a solution for end-to-end encrypted conference calls. > We implemented this in Google a couple of years ago in Duo, but the draft > was only published last month given the current interest in the topic. > > > > The goal of the session is to go through the proposal and see if there is > interest to continue working on this, and if so what will be the best WG = to > host this work. > > > > Thanks > > Emad > > > > On Mon, Jun 15, 2020 at 11:02 AM Ben Campbell wrote: > > Hi Emad, > > > > We prioritize DISPATCH meeting time to focus on topics that have had > DISPATCH list discussion and need high-bandwidth time to resolve. Unless > I=E2=80=99ve missed something, this topic has not previously come up in D= ISPATCH. I > suggest sending a note to this list with some background about the draft > and how you would like to see it progress. > > > > Thanks! > > > > Ben. > > > > On Jun 15, 2020, at 12:32 PM, Emad Omara < > emadomara=3D40google.com@dmarc.ietf.org> wrote: > > > > Hi, > > > > We would like to have a session in the next IETF to discuss the SFrame > draft Can you please > help scheduling this? > > > > Thanks > > Emad > > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > > > > -- > Sframe mailing list > Sframe@ietf.org > https://www.ietf.org/mailman/listinfo/sframe > --000000000000e849e605a8faaf32 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi roni,

Those are great points.
<= div>
With respect to EKT, we believe that just=C2=A0like doub= le and EKT were two separate matters even though there=C2=A0were both neede= d to get a complete system to work, media encryption (SFrame) and key distr= ibution should be separated. One of the argument in favor of separation is = that while media encryption will likely be the same in nature whether you d= o video conferencing, or streaming, or other media use cases, the trust / t= hreat=C2=A0model can be vastly different, and thus require different key ex= change mechanisms.

With respect to RTP, and I beli= eve emad is working on writing a draft as we speak.

regards,


On Fri, Jun 26, 2020 at 10:18 AM Roni Even &= lt;ron.even.tlv@gmail.com>= wrote:

Hi,

<= u>=C2=A0

I find this pr= oposal interesting since the issue of key distribution in multipoint confer= ences is a problem even if the media mixer (any topology) is a trusted enti= ty and wants to distribute the encrypted media without doing decrypt/encryp= t cycle.=C2=A0 One point to look at is that in the past when we designed RF= C5764 (DTLS/SRTP) the consensus was that key exchange must be done in-band.=

As far as I rememb= er one of the motivation point for EKT in AVT was to address the key distri= bution for multipoint conferences.

=C2=A0

As for the work, if there is a consensus to accept this work, it will re= quire support for RTP. How to signal that this is such a payload and what s= hould be the RTP PT in the RTP header. (how to negotiate what is the secure= payload inside the SFRAME)

= On one hand it may look like a new RTP payload (similar to MPEG2 RT= P payload (RFC2250)) and as such is in scope for AVTCore but as for the fra= mework I think this is not AVTCore work.

=C2=A0

Roni Even

= AVTCore co-chair

= =C2=A0

=C2=A0=

=C2=A0

From: dispatch [mailto:dispatch-bounces@ietf.org] = On Behalf Of Patrick McManus
Sent: Monday, June 15, 2020 10:0= 6 PM
To: Emad Omara
Cc: Ben Campbell; Dispatch WG; sframe@ietf.org
= Subject: [dispatch] Dispatch of SFrame for End-To-End Encrypted Confere= nce Calls

=C2=A0

Hi All -

I failed= to note the link highlighting in Emad's mail to the list which already= contained the draft. Sorry about that. (It's=C2=A0https://tools.i= etf.org/html/draft-omara-sframe-00=C2=A0if you too missed it).

T= here's also a github and mailing list referenced:
https://github.com/eomara/sfra= me
https://mailarchive.ietf.org/arch/browse/sframe/?=

=C2=A0

<= p class=3D"MsoNormal">[I've also forked the Subject Line to help intere= sted readers]

= =C2=A0

On Mon, Jun 15, 2020 at 2= :42 PM Patrick McManus <patrick.ducksong@gmail.com> wrote:

=

Sounds really inter= esting Emad and there's obviously related=C2=A0work going on (at least = perc, maybe even mls..).

=C2=A0

Sending that email Ben= mentions to the dispatch list to raise awareness with a link to the draft = would be helpful in getting the process started..

=C2=A0

On Mon, Jun 15, 2020 at 2:33 PM Emad Omara <emadomara@google.com> wrote:<= u>

Hi= Ben,

=C2=A0

=

This draft proposes a solution for end-to= -end encrypted conference calls. We implemented=C2=A0this in Google a coupl= e of years ago in Duo, but the draft was only published last month given th= e current interest in the topic.

=C2=A0

The goal= of the session is to go through the proposal and see if there is interest = to continue working on this, and if so what will be the best WG to host thi= s work.=C2=A0

=C2= =A0

Thanks

Emad

=C2=A0

On = Mon, Jun 15, 2020 at 11:02 AM Ben Campbell <ben@nostrum.com> wrote:

Hi Emad,

=C2=A0

We prioritize DISPATCH meeting time to focus on topics that= have had DISPATCH list discussion and need high-bandwidth time to resolve.= Unless I=E2=80=99ve missed something, this topic has not previously come u= p in DISPATCH. I suggest sending a note to this list with some background a= bout the draft and how you would like to see it progress.

=

=C2=A0

Thanks!

=C2=A0

Ben.



On Jun 15, 2020, at 12:32 PM, Emad Omara <emadomara=3D4= 0google.com@dmarc.ietf.org> wrote:

=C2=A0

Hi,=

=C2=A0

We would like to have a session in the next IE= TF to discuss the SFrame draft=C2=A0Can you please help scheduling= this?

=C2=A0<= /u>

Thanks

Emad

_______________________________________________
dispatch mailing l= ist
dispatch@ietf= .org
https://www.ietf.org/mailman/listinfo/dispatch<= /u>

=C2=A0

--
Sframe mailing list
Sframe@ietf.org https://www.ietf.org/mailman/listinfo/sframe
--000000000000e849e605a8faaf32--