From nobody Wed Sep 1 14:37:03 2021 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 5F4CB3A0C04 for ; Wed, 1 Sep 2021 14:37:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.101 X-Spam-Level: X-Spam-Status: No, score=-2.101 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=lowentropy.net header.b=RbWV5shL; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=JYIcch/x 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 3gyVdBG_P07p for ; Wed, 1 Sep 2021 14:36:55 -0700 (PDT) Received: from wout3-smtp.messagingengine.com (wout3-smtp.messagingengine.com [64.147.123.19]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6345A3A0C03 for ; Wed, 1 Sep 2021 14:36:55 -0700 (PDT) Received: from compute5.internal (compute5.nyi.internal [10.202.2.45]) by mailout.west.internal (Postfix) with ESMTP id 615A83200986; Wed, 1 Sep 2021 17:36:53 -0400 (EDT) Received: from imap41 ([10.202.2.91]) by compute5.internal (MEProxy); Wed, 01 Sep 2021 17:36:53 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lowentropy.net; h=mime-version:message-id:date:from:to:cc:subject:content-type; s=fm3; bh=1q+LCLNesDtJKQ/ZD3tjvC5rJ9D7y0m9hZba170KFTQ=; b=RbWV5 shLqalONzQxU4McwZuetKXz8QccH1RzgL7k8KRAIzm1pvqZ3Ua/ZL3PnRq7t2u71 2sdlAWtqJofqD6z0JPxSzQakLFv1NddqaA8ici07RLtQOc9yy540z6GeJT5wjpXu UmNhQpLP373ITCsfPIqwkPPZZ20UrE3SVh/AyKF9xpYTtVAKUQPQIbF4Axm3jQHw B2NXlk86icnfVdgnAOutXmWXuF5033ukjZywM7+VTaOvUuRo/oYttnNeLLbPrxN4 KXat6APo1+EIpHDlG8Dr5ZWj++aoTu2X94bhRQxwW2evDQpdTRdwPhLI8YbADj7U HFKNXn7FbBvvogpYw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:from:message-id :mime-version:subject:to:x-me-proxy:x-me-proxy:x-me-sender :x-me-sender:x-sasl-enc; s=fm3; bh=1q+LCLNesDtJKQ/ZD3tjvC5rJ9D7y 0m9hZba170KFTQ=; b=JYIcch/xBNgCpgY6b2QG1gbWM3Dn/trrAX5VK4Tx2UNGH A/elMLEySJRwTVVdbgoLBBOBz9xl/TUwoxxIHLdyWOnT2I6oBLuGIlNYkBSZ5Nic tYL30SU8oSS+I4dGAcB4dxoGn5e0jneUas7w0D7YpXyURCKwx8EnULOpf/ZhPrwD ugSszBzcXiIY7R9oh/kkQ6WjRnemGOrletwkKjatMUmjus4EGdyxoDpDS8+B6BHa PifEnADnspg6RrwZyLHIFaAVIwvZAYI2j9bE5g9MJ+rbhKB8tpDaSpNkZA6Bg3mg 8DaFpcs9eB9zDpVj/yisV6/L4yVPo45/9N+6zQjDg== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvtddruddvfedgudeiudcutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh necuuegrihhlohhuthemuceftddtnecunecujfgurhepofgfggfkfffhvffutgesthdtre dtreertdenucfhrhhomhepfdforghrthhinhcuvfhhohhmshhonhdfuceomhhtsehlohif vghnthhrohhphidrnhgvtheqnecuggftrfgrthhtvghrnhepgfehieeggfeileekhfdthf dtffegjeffvdekudffgfeltddujefhieeihffhveegnecuffhomhgrihhnpehivghtfhdr ohhrghenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpe hmtheslhhofigvnhhtrhhophihrdhnvght X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 53B0E3C0AEC; Wed, 1 Sep 2021 17:36:52 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.5.0-alpha0-1126-g6962059b07-fm-20210901.001-g6962059b Mime-Version: 1.0 Message-Id: <08dbdcc3-313e-47e8-babc-055d0084c2de@www.fastmail.com> Date: Thu, 02 Sep 2021 07:36:32 +1000 From: "Martin Thomson" To: sframe@ietf.org Cc: Bobo , "Murray Kucherawy" Content-Type: text/plain Archived-At: Subject: [Sframe] Cancellation of interim X-BeenThere: sframe@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Secure Media Frames List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Sep 2021 21:37:02 -0000 Apologies for delaying this, but the chairs have conferred and - as we don't have an anything to discuss[*] - we are cancelling the interim scheduled this week. Work continues, even if it is not evident from the activity here. We'll look at organizing another interim once we have something to interim about. [*] Aside perhaps from https://mailarchive.ietf.org/arch/msg/sframe/9v67vDX5quYtOIdrdd6SL1CsuOU/ which we can continue via email. We don't need to take 2 hours for that. From nobody Wed Sep 1 14:37:50 2021 Return-Path: X-Original-To: sframe@ietf.org Delivered-To: sframe@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B5403A0C06; Wed, 1 Sep 2021 14:37:48 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IESG Secretary To: "IETF-Announce" Cc: sframe-chairs@ietf.org, sframe@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.36.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <163053226727.6317.13705849366300779476@ietfa.amsl.com> Date: Wed, 01 Sep 2021 14:37:47 -0700 Archived-At: Subject: [Sframe] Secure Media Frames (sframe) WG Interim Meeting Cancelled (was 2021-09-02) X-BeenThere: sframe@ietf.org X-Mailman-Version: 2.1.29 List-Id: Secure Media Frames List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Sep 2021 21:37:48 -0000 The Secure Media Frames (sframe) virtual interim meeting for 2021-09-02 from 19:00 to 21:00 UTC has been cancelled. From nobody Thu Sep 2 13:19:40 2021 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 47F0C3A0A42 for ; Thu, 2 Sep 2021 13:19:38 -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 UuZiYG3BTiBU for ; Thu, 2 Sep 2021 13:19:33 -0700 (PDT) Received: from mail-qv1-xf2a.google.com (mail-qv1-xf2a.google.com [IPv6:2607:f8b0:4864:20::f2a]) (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 63DF83A0A33 for ; Thu, 2 Sep 2021 13:19:33 -0700 (PDT) Received: by mail-qv1-xf2a.google.com with SMTP id eh1so1936731qvb.11 for ; Thu, 02 Sep 2021 13:19:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ipv-sx.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to; bh=NXIbeu4H+W8KsZUgXfJmzcClbdCAyHwsZYsOKR2w9GI=; b=gk2zmSS6C8/orljYETn0JwR2CqR8YyrceZHpsh7Fn5ryP0VOZyIc4ksQ6PCI13JgFt UzoQRrVYzF3L2V9V2MrOnrQYjmB2oAa4g+jdIqSIKibjHm44YSEWsCvTqn4M3th77/nI KQ+ZeksN2iM2qbF5QE1wJoLSLxOq1KHF9sN3ag2z6URRv3iWENCQaaVOw8CLL3apz1kX pLM7cvybpMN0LJJq/VEei/prcKvvBUlS6kzcZ9CpR2xhZpDu9LYmdpjMEeDejoW9c0Iz QKMNuY2f2rBdLPj7rh7QEssNAkOSorcjvWNcJA+4LvKfB616hbpJ8i7USEeDXltNF8la HwqA== 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=NXIbeu4H+W8KsZUgXfJmzcClbdCAyHwsZYsOKR2w9GI=; b=DS+dlyTpxmrNL7d3Z9d76yema7iwnPI7TIvIt+/xnSNTYa8DCVhIjcz9qd5+4Lq7T/ PJXroWn4XhuBOA5MtBpjdVTckfDDdnz2NH3Ixsx0Qpce82ZkjqZh+z3YUWUYHFIg+CjN 8wiMGkMcWpBs/UyXIY+aesD4x2nJwBmUwJzzUhqhO4aW3+2cEOAKjxJx7VhUzTPrtHEJ Kg7OHEtzXiVxn65ACJ2ow95/dh7W7NKrvy9iGszTGA/MXL9NiHbEXYeJfqFfDNceIc4n YmyrLmyyPjCsT8krl5ES59izqVZbVIVpaJjQs6zWsecEeQJWBzUcTODdSXgcWs3pOeSC zaUw== X-Gm-Message-State: AOAM5307+W+fuHyYjK6mvRqkwYGtmdwj03ttBXrK+5XGHb426pJeR9kq Xi7ZfnPopzjf5v2C9S69qc3bnq/KPP6RS1k6E47bPW1URkpzTA== X-Google-Smtp-Source: ABdhPJzNkdmerPZtIyZ1Xag30Th8wS5Oj/y3OaogmlX6Dj+sSOlfJXpq4F8Z8YcJ9f7uQsL8cIel6rUodbmBRwmU0HM= X-Received: by 2002:a0c:8029:: with SMTP id 38mr52214qva.31.1630613971159; Thu, 02 Sep 2021 13:19:31 -0700 (PDT) MIME-Version: 1.0 From: Richard Barnes Date: Thu, 2 Sep 2021 16:19:19 -0400 Message-ID: To: sframe@ietf.org Content-Type: multipart/alternative; boundary="000000000000845c8b05cb08e6d3" Archived-At: Subject: [Sframe] Implementation report: SPacket in Webex X-BeenThere: sframe@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Secure Media Frames List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Sep 2021 20:19:39 -0000 --000000000000845c8b05cb08e6d3 Content-Type: text/plain; charset="UTF-8" Hi folks, I wanted to share some implementation news: Webex has shipped SFrame as part of its new end-to-end encrypted meetings feature [1], using an open-source SFrame stack in C++ [2]. It is now being used for several thousand meetings per day. A few findings: 1. Keys for SFrame are provided from an MLS group associated to the meeting. In particular, this means that the SFrame keys change whenever someone joins or leaves the meeting. This works smoothly as long as the key roll-over is coordinated so that senders don't encrypt with the new key before receivers have it to decrypt with. 2. The SFrame encryption framing is applied to individual RTP media payloads, as opposed to full frames (i.e., this is "SPacket".) This approach made integration very simple; you simply add an SFrame protect/unprotect whenever you do an SRTP protect/unprotect. Everything else, including things like recovery, works as before. 3. With the algorithms and parameters we are using (AES-GCM, E=4), the overall bandwidth overhead from SFrame in a typical meeting with voice, video, and content share is around 80kbps. Applying SFrame per-frame in this setting would reduce this to about 45kbps. With a base bandwidth of around 3Mbps, this puts SFrame at around 3% overhead per-packet / 1.5% per-frame. 4. SFrame usage is not signaled in SDP, much like the WebRTC uses of SFrame based on Insertable Streams. Overall, SFrame seems to be working well for this use case. We should carry on getting it an RFC number :) --Richard [1] https://www.cisco.com/c/en/us/solutions/collateral/collaboration/white-paper-c11-744553.html [2] https://github.com/cisco/sframe --000000000000845c8b05cb08e6d3 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi folks,

I wanted to share some implementation new= s: Webex has shipped SFrame as part of its new end-to-end encrypted meeting= s feature [1], using an open-source SFrame stack in C++ [2].=C2=A0 It is no= w being used for several thousand meetings per day.

A few findings:<= br>
1. Keys for SFrame are provided from an MLS group associated to the = meeting.=C2=A0 In particular, this means that the SFrame keys change whenev= er someone joins or leaves the meeting.=C2=A0 This works smoothly as long a= s the key roll-over is coordinated so that senders don't encrypt with t= he new key before receivers have it to decrypt with.

2. The SFrame e= ncryption framing is applied to individual RTP media payloads, as opposed t= o full frames (i.e., this is "SPacket".) =C2=A0This approach made= integration very simple; you simply add an SFrame protect/unprotect whenev= er you do an SRTP protect/unprotect.=C2=A0 Everything else, including thing= s like recovery, works as before.

3. With the algorithms and paramet= ers we are using (AES-GCM, E=3D4), the overall bandwidth overhead from SFra= me in a typical meeting with voice, video, and content share is around 80kb= ps.=C2=A0 Applying SFrame per-frame in this setting would reduce this to ab= out 45kbps.=C2=A0 With a base bandwidth of around 3Mbps, this puts SFrame a= t around 3% overhead per-packet / 1.5% per-frame.

4. SFrame usage is= not signaled in SDP, much like the WebRTC uses of SFrame based on Insertab= le Streams.

Overall, SFrame seems to be working well for this use c= ase.=C2=A0 We should carry on getting it an RFC number :)

--Richard<= br>
[1] https://www.cisco.com/c/en/us/solu= tions/collateral/collaboration/white-paper-c11-744553.html
[2] https://github.com/cisco/sframe<= /div> --000000000000845c8b05cb08e6d3-- From nobody Thu Sep 2 13:20:10 2021 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 A6A7E3A0A34 for ; Thu, 2 Sep 2021 13:20:08 -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, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=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 rdpNAONblLK2 for ; Thu, 2 Sep 2021 13:20:05 -0700 (PDT) Received: from mail-qv1-xf33.google.com (mail-qv1-xf33.google.com [IPv6:2607:f8b0:4864:20::f33]) (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 4617E3A0A5E for ; Thu, 2 Sep 2021 13:20:05 -0700 (PDT) Received: by mail-qv1-xf33.google.com with SMTP id 93so1300743qva.7 for ; Thu, 02 Sep 2021 13:20:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ipv-sx.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to; bh=eV/l7rf/Re7fvfu6yBQndvuCkODCKkFN9SegQ7ZtbP0=; b=YaMpU8d3ZmFESVVuaAtUuwIS2qeIthCetc79R0bbBhtfFjPkQjMKGJFuTyT8ZB1zqf an4rIaXsWzLS1UXiK1cESxMilNIhannz2UX6tzq0Bqpr/GPIubpwztJxdrbXKKsh1EF1 0yTBzdYr+eoVH7/ahIzN1QE2/TIpGYsbSEcYNBeCItpA/aW9OrW+/5UHr4KLxH42f9Nw c8HFUpJW2Cdxml6ifLnRCIive+MBhhmO6bvFplHZIqiN4Dg5bbd8VdvGpXUHfO58RMsY C2z/oDTrugHFgm0Pt8u4g2zXkRdQmywWxi/eQ4nzA/RiAyU4xB1Vcby4874/W4/gTceF qWTw== 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=eV/l7rf/Re7fvfu6yBQndvuCkODCKkFN9SegQ7ZtbP0=; b=IYwdaIRrcpER7ycYEuSg4bGC+eZA5iSNdfL5aISLUZtAi8p4xMOu3RtSfD6HvIjgDm O+B5GfWg6u7UrWaCarwtaEiWc/oWb18+YrB3BL18XgMihE0MtpJ/OM3+HyCrn4NlirBl I54OCAHnQ4vE/+9Joq5ltFc0aNAsxrM2yuSQngpRdb2VWt/i+yvgfy4P68julZcfhkk2 NraJX400pz2oP2WMlnEAEBgxoRg11IZQbavMo4cSBKi/t7GPAUNFALkvcKrF0PgJFnWD LZXtsOinZx1p9Bu2Bg34+tLEBbjg9sIFccAMPXDtHa2bOM175WiJ2Mv9s9s4c+mAUhZL oLjg== X-Gm-Message-State: AOAM531piAcjKEU/4yNUNuYx95AbLgiUd0m5i1eNGlZOlK6d/wnPmWa6 Y+I3kIjNodInmfLrwm2UBa1T+1kcIA5/6VCI9uUedB8z767SKQ== X-Google-Smtp-Source: ABdhPJwi7IMfSROw16fGLtZvrjQxKxL/rT/f9ExuEvVLuRbYlAoJ4uzgxYSUgnZvCMzLegd5D11Bm7wyLPJjp0ryUao= X-Received: by 2002:a0c:cc8f:: with SMTP id f15mr124132qvl.47.1630614002866; Thu, 02 Sep 2021 13:20:02 -0700 (PDT) MIME-Version: 1.0 From: Richard Barnes Date: Thu, 2 Sep 2021 16:19:50 -0400 Message-ID: To: sframe@ietf.org Content-Type: multipart/alternative; boundary="000000000000682a8d05cb08e8af" Archived-At: Subject: [Sframe] Propose to adopt draft-omara-sframe and draft-barnes-sframe-mls X-BeenThere: sframe@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Secure Media Frames List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Sep 2021 20:20:09 -0000 --000000000000682a8d05cb08e8af Content-Type: text/plain; charset="UTF-8" Hi folks, There hasn't been much discussion here on these drafts, but I get the impression that folks pretty much agree that these drafts should be the starting points for meeting the WG's milestones. draft-omara-sframe for the milestone already in the charter, and draft-barnes-sframe-mls for the milestone implied by the last paragraph. Chairs: Could we please do an adoption call for these drafts? Thanks, --Richard --000000000000682a8d05cb08e8af Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi folks,

There hasn't been much discussion her= e on these drafts, but I get the impression that folks pretty much agree th= at these drafts should be the starting points for meeting the WG's mile= stones. =C2=A0draft-omara-sframe for the milestone already in the charter, = and draft-barnes-sframe-mls for the milestone implied by the last paragraph= .

Chairs: Could we please do an adoption call for these drafts?
<= br>Thanks,
--Richard
--000000000000682a8d05cb08e8af-- From nobody Thu Sep 2 13:20:37 2021 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 24B053A0A8E for ; Thu, 2 Sep 2021 13:20:35 -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, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=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 Y2RYbiCnGjD9 for ; Thu, 2 Sep 2021 13:20:33 -0700 (PDT) Received: from mail-qv1-xf29.google.com (mail-qv1-xf29.google.com [IPv6:2607:f8b0:4864:20::f29]) (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 8D0F43A0A71 for ; Thu, 2 Sep 2021 13:20:33 -0700 (PDT) Received: by mail-qv1-xf29.google.com with SMTP id p17so1941408qvo.8 for ; Thu, 02 Sep 2021 13:20:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ipv-sx.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to; bh=lnnS5yGUKzoU/5F8J05FNLQcemUqz7gTkXqyNqAxv/0=; b=NUc4vcPRaT1T8JBwTom74hq5XusxzBvo5/ROW/utU+UVeSD2QD1+QtHPGmHUP/RewJ dRRLO06i/4pl/AWmQ8YqIDCBBYrc9CbUM8+L42Qfz1gHYEW+57TJtEYpk+uqfp9YdVo5 nYM+UykGXrTLWPOukvUh8uFJwpBx7aNyDYfyT3tT+pac+xjrevYiaNmLCrOlF0raLkiW adfjViBFg+Rx9tdBiAYbapIY+bGlWD6GLkChT59q/eW6z832tWxQl35VexrG6kUdTRsA EiaQ6ygrTMigsq5wvKc1ItR3QmfcAybCJOOsS21bv0hi48LN96sKKAP9u+VliZbrJDDr /PnQ== 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=lnnS5yGUKzoU/5F8J05FNLQcemUqz7gTkXqyNqAxv/0=; b=KfeRC+25P2xS1ZqPQV0bEhK7ER0AKKdANZSb6YfXBKw/Qu884CbVoAV9YcmcAGqGly L3JtjuUL3JMfnVRoCKOH6ru7xshDE27wJN7ymyi4RtLjN2dl00LnAWFbBxp2Zg8Ybf5h eyPA5/Vu77UPDT7IBfqxBCROhf35abqpnDU6yQrd59aVf1lapA+Xl7gWbF1TDj5gv8R9 h14TcLA7vEteFPcYeQwAOLywSzgYfuM4wfJW2Rp5DfgOtxj3Tgv7nCi1XJ2ROGLwJtma iFruBGTEwJjcT1vv0JGRmmVy8I3Tt+ysgw88dJfHfVRnl+6bh095imUrjyOyNiQ2jWBR +KdQ== X-Gm-Message-State: AOAM533pBe9tIBRIebfU3rL8H9m3Pv8fNVyogrnnQOFgKgdkDYyRarEW ixu5+XTzwSnf1aS/KNPfHobQ0aMyAEq5lPYjfRVp+ZXYumOUbg== X-Google-Smtp-Source: ABdhPJzMprxG7+jSk1pHCHMzwxhGoShJQrklXg0QmzyLYV/m+VeOrYCdJHD4ajl21xEjlnZ3uhQYnvuEExzFyVNxFQ8= X-Received: by 2002:ad4:46f0:: with SMTP id h16mr118467qvw.0.1630614030627; Thu, 02 Sep 2021 13:20:30 -0700 (PDT) MIME-Version: 1.0 From: Richard Barnes Date: Thu, 2 Sep 2021 16:20:18 -0400 Message-ID: To: sframe@ietf.org Content-Type: multipart/alternative; boundary="0000000000000fc44205cb08ea53" Archived-At: Subject: [Sframe] Proposal: SFrame && SPacket && !SIDU X-BeenThere: sframe@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Secure Media Frames List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Sep 2021 20:20:35 -0000 --0000000000000fc44205cb08ea53 Content-Type: text/plain; charset="UTF-8" Hi folks, I'd like to see if we can agree to limit our scope a bit. There has been discussion of multiple levels at which SFrame could be applied: * "SFrame" - Whole media frames * "SPacket" - Individual RTP media payloads * "SIDU" - Some codec-specific "independently decodeable units" I'd like to propose that we take "SIDU" off of the table, but keep the other two. It seems like SFrame and SPacket both have strengths in certain scenarios (depending on how you want to trade off bandwidth vs. complexity), but they're both pretty straightforward in terms of how they integrate with the media processing pipeline. In particular, they don't have any codec-dependence. SIDU, by contrast, seems like a world of pain. It requires that the encryption scheme be entangled with the codec, which requires special per-codec integration logic in the specifications. And the bandwidth gains for all that complexity are not that large. Is there anyone here who feels that SIDU is something this group needs to spend time specifying? --Richard --0000000000000fc44205cb08ea53 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi folks,

I'd like to see if we can agree to li= mit our scope a bit.=C2=A0 There has been discussion of multiple levels at = which SFrame could be applied:

* "SFrame" - Whole media fr= ames
* "SPacket" - Individual RTP media payloads
* "SI= DU" - Some codec-specific "independently decodeable units"
I'd like to propose that we take "SIDU" off of the tabl= e, but keep the other two.

It seems like SFrame and SPacket both hav= e strengths in certain scenarios (depending on how you want to trade off ba= ndwidth vs. complexity), but they're both pretty straightforward in ter= ms of how they integrate with the media processing pipeline.=C2=A0 In parti= cular, they don't have any codec-dependence.=C2=A0 SIDU, by contrast, s= eems like a world of pain.=C2=A0 It requires that the encryption scheme be = entangled with the codec, which requires special per-codec integration logi= c in the specifications.=C2=A0 And the bandwidth gains for all that complex= ity are not that large.

Is there anyone here who feels that SIDU is = something this group needs to spend time specifying?

--Richard
--0000000000000fc44205cb08ea53-- From nobody Thu Sep 2 13:23:32 2021 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 5EAF73A0ABB for ; Thu, 2 Sep 2021 13:23: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 M-bv73hk82yx for ; Thu, 2 Sep 2021 13:23:26 -0700 (PDT) Received: from mail-qt1-x82a.google.com (mail-qt1-x82a.google.com [IPv6:2607:f8b0:4864:20::82a]) (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 E2B903A0AB6 for ; Thu, 2 Sep 2021 13:23:25 -0700 (PDT) Received: by mail-qt1-x82a.google.com with SMTP id t35so2729847qtc.6 for ; Thu, 02 Sep 2021 13:23:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ipv-sx.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to; bh=Ek4T4b/QnoZjaDAURgD2ShrmlH9sofVbKrhvHW/ie0g=; b=RqfTOK7H0KipenSgbFDqeV7nBlSNadnxN50KdRvvJFBVyV9OBoaI36QRL4Dmip5hLd LSlNI0pT7Zj2OWqUo/E8peonZnz35ewjE9JphKOxuCMjmfcxu7E3VbsXc7O7Jk57vRri fipsADJWuNQD4zxSZi5njMp+JySvj0i6jCOGV/h6wsH+QgjvjNOEcXA4yB0U5CODgoQp mBJ0EAPzlRUQsRyjGhkEoWOA248K0qrQkyxgesUkx8dfc6eGw1uDDV/u2hzlhmTMGGzx Lol5hWpdlxxca+TanDynfHs7Yihg3dtD9TvjZ/TI273/Np4F9TxseA8aWH/2udsF0ZR7 Dzlw== 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=Ek4T4b/QnoZjaDAURgD2ShrmlH9sofVbKrhvHW/ie0g=; b=oX7xYPzvO/lSPpck1oShdedC3pjrl3UzRfZEbY01R34CgwMNdWVFGRxfeVULYenvNF mfS1hS2lYHAQ72OkgWR/UtDrNN30wAFPyOdBYSLQ/rlse5l7m4NZ44nW1JDKDcaC5ceS M0BczAZVqQNZ/uq5w1KDIR3JdUpbv+kT8azW/EAyRcNHd3PDNjyqptm5T7+6L8rDpYfv fO4QTYDlqs187//AEBqVQyFbB4fHdKAf79+3xo34wQMEmzdWogFAySWZEfyiyKTL+9cU LD4vZI3UeBCmfi2tQkI3aeEryxQwVkOPke2xUDU+qT04jCAieMtQGZ1+8jjcNgEIH/H5 SNHw== X-Gm-Message-State: AOAM533gzmTV5rBunC4E62cR44wTuF4JIUhj70TLuAY0HV3kIjS1nGa8 7HAAAPzPvBiOLgAU5AI6vgVlrfCJTFeMyv2MFo4yajI6OoqaVg== X-Google-Smtp-Source: ABdhPJxtRu4Ma0b++CyTo1zIbzbRd7wb6Uk0l0IdG/jjUkty4fY6JwXLFwtoOtZm0F9cZv76iIMlsOsjDuUg1zALb+0= X-Received: by 2002:ac8:7a98:: with SMTP id x24mr154182qtr.265.1630614204177; Thu, 02 Sep 2021 13:23:24 -0700 (PDT) MIME-Version: 1.0 From: Richard Barnes Date: Thu, 2 Sep 2021 16:23:12 -0400 Message-ID: To: sframe@ietf.org Content-Type: multipart/alternative; boundary="00000000000067f4dd05cb08f41e" Archived-At: Subject: [Sframe] Negotiating SFrame/RTP in SDP X-BeenThere: sframe@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Secure Media Frames List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Sep 2021 20:23:31 -0000 --00000000000067f4dd05cb08f41e Content-Type: text/plain; charset="UTF-8" Hi folks, One of the major work items left around SFrame is the work to specify how SFrame-encrypted media are carried in RTP, and how that is signaled in SDP. The finer points might need to be worked out in AVTCORE / MMUSIC, but since this group knows the intricacies better, it seems like having some agreement here on general approach would be good. Sergio put together a first stab at this in draft-murillo-avtcore-multi-codec-payload-format [1]. He presented this at AVTCORE @ IETF 111 [2]. Unfortunately, the discussion there doesn't seem to have provided a clear path forward, thus this thread. Personally, I think the proposal in Sergio's draft is a little wide of the mark. ISTM that specifying a "generic" media format and recovering the specificity in an RTP header is more complex than is needed. Worse, it sets up implementations to send the same media both encrypted and unencrypted -- obviously not great for security. I'd like to propose a simpler approach, drawing inspiration from cryptex [3]: a=sframe: [] Basically, just a new SDP attribute per m-line, that specifies that SFrame encryption is being done and how. The desired semantic is clear for SPacket: Just add an SFrame protect/unprotect before you do other processing on the media payload. Then you will have a payload that is as described in the SDP. You can *almost* describe SFrame in this way as well. Assemble all the RTP packets in a frame, then do SFrame across all of their payloads (in particular, adding the header to the first packet and the tag to the last). If you constrained the sender to construct pre-SFrame packets that were properly packetized according to the rest of the SDP, then this would integrate cleanly with the rest of the SDP/RTP model. The problem is that that constraint is incompatible with Insertable Streams. So we need to decide how much we care about compatibility with IS as it is. Personally, it seems like WebRTC stacks and web apps are going to have to upgrade *anyway* if they're going to support SDP-based negotiation of SFrame, so if they have to make this one extra change, it shouldn't be a big deal. How does this approach strike folks? --Richard [1] https://www.ietf.org/archive/id/draft-murillo-avtcore-multi-codec-payload-format-01.html [2] https://youtu.be/S-JR4Fa8VFY?t=3510 [3] https://www.ietf.org/archive/id/draft-ietf-avtcore-cryptex-02.html#name-signaling --00000000000067f4dd05cb08f41e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi folks,

One of the major work items left around S= Frame is the work to specify how SFrame-encrypted media are carried in RTP,= and how that is signaled in SDP.=C2=A0 The finer points might need to be w= orked out in AVTCORE / MMUSIC, but since this group knows the intricacies b= etter, it seems like having some agreement here on general approach would b= e good.

Sergio put together a first stab at this in draft-murillo-av= tcore-multi-codec-payload-format [1].=C2=A0 He presented this at AVTCORE @ = IETF 111 [2].=C2=A0 Unfortunately, the discussion there doesn't seem to= have provided a clear path forward, thus this thread.

Personally, I= think the proposal in Sergio's draft is a little wide of the mark.=C2= =A0 ISTM that specifying a "generic" media format and recovering = the specificity in an RTP header is more complex than is needed. Worse, it = sets up implementations to send the same media both encrypted and unencrypt= ed -- obviously not great for security.

I'd like to propose a si= mpler approach, drawing inspiration from cryptex [3]:

a=3Dsframe:<= ;frame|packet> [<keying>]

Basically, just a new SDP attribu= te per m-line, that specifies that SFrame encryption is being done and how.= =C2=A0 The desired semantic is clear for SPacket: Just add an SFrame protec= t/unprotect before you do other processing on the media payload.=C2=A0 Then= you will have a payload that is as described in the SDP.

You can *a= lmost* describe SFrame in this way as well.=C2=A0 Assemble all the RTP pack= ets in a frame, then do SFrame across all of their payloads (in particular,= adding the header to the first packet and the tag to the last).=C2=A0 If y= ou constrained the sender to construct pre-SFrame packets =C2=A0that were p= roperly packetized according to the rest of the SDP, then this would integr= ate cleanly with the rest of the SDP/RTP model.=C2=A0 The problem is that t= hat constraint is incompatible with Insertable Streams.=C2=A0 So we need to= decide how much we care about compatibility with IS as it is.=C2=A0 Person= ally, it seems like WebRTC stacks and web apps are going to have to upgrade= *anyway* if they're going to support SDP-based negotiation of SFrame, = so if they have to make this one extra change, it shouldn't be a big de= al.

How does this approach strike folks?

--Richard

[1]= https://www.ietf.org/archive/id/draft-murillo-av= tcore-multi-codec-payload-format-01.html
[2] https://youtu.be/S-JR4Fa8VFY?t=3D3510
[3]= https://www.ietf.org/archive/id/draft-ietf-avtcore-cryp= tex-02.html#name-signaling
--00000000000067f4dd05cb08f41e-- From nobody Thu Sep 2 14:11:54 2021 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 AF9913A112F for ; Thu, 2 Sep 2021 14:11:51 -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 XY5lhGoBJKDY for ; Thu, 2 Sep 2021 14:11:46 -0700 (PDT) Received: from mail-lf1-x129.google.com (mail-lf1-x129.google.com [IPv6:2a00:1450:4864:20::129]) (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 58AC63A112C for ; Thu, 2 Sep 2021 14:11:46 -0700 (PDT) Received: by mail-lf1-x129.google.com with SMTP id m28so7266733lfj.6 for ; Thu, 02 Sep 2021 14:11:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=6jU6qX7jppQcT49j6cCprlTOLlauIDRDQpUzX24bgJI=; b=Aq0xAk0w+evm9QTmBNYJ+8ovLQCK63BOE9+DDaTQ2hckQ4b9gpF/92qdfnSkkULIAL 3phwAON4c53gqhLcLIPOwY1vDNJog9IAZHA15hr0bB65jEhit7yDOs31flfCJDgoLaN2 wF/VczHK+MK5xJWuZngRlzW7216N7EAv0MIoS1E9sOVYBvWF22OSdSx67F6vULspTmtL O1Xqf+wtFZdH4dENI7NUqJH0wLStxI/6w0E55U0HROAqgjwIbvYhLRqInJSV8P//vN4/ jPRKwlfJnt2IR0wLLH5a035Sa6cHW79qX7dwiCbC1WbDbZt7PrAZB6fkcdg7hR+Q6NGP dupw== 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=6jU6qX7jppQcT49j6cCprlTOLlauIDRDQpUzX24bgJI=; b=q6zAk8cCL5zEetNHaGoaVVejZB48Ka03auhaIF5vCmg/InYZcV/nxSrxbGosDFeUIj 4cyLn9xo55m632dmWTOgHcZnEqdOw/5twP9bGtDybqdmxf/uF4HUnXSc5runpgFRUABF byNXwnSjeRQ2dB+t7JvmUtA4qA7AHyVnxFUuA4S493gNTGUcXXOuLHNXM+evV1aMXI5q LZTT+RMRqGch2s5nUzOzcd1uf1FRG8TmNkrlo2zTbVYnCZJ6Vq4fhviVDpwT7kqUuPbV Oos36ez7FVQRKUcXlHPozUHcSj3OQpapZPzOnl+Rkfg+bgr2mNNSEO/yTIQrBw8+EGR2 XLqQ== X-Gm-Message-State: AOAM533DV3Aa/23j0IZXSmIjrdOFNX4oyLAzBY97L94MT2kZEjTV3X3m aNvQKY5IZEr6mNZRNN3RFS46ojAdw0ulIr91eKre8lKK X-Google-Smtp-Source: ABdhPJxycep4WUGtAyYoC+bmh6FBQjGcf2RH9TENU4MT5i1cvuP3w/DMcxHMzON0LFPvF6697iZqC148LcTklALswAI= X-Received: by 2002:a05:6512:31e:: with SMTP id t30mr123503lfp.218.1630617102331; Thu, 02 Sep 2021 14:11:42 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Bernard Aboba Date: Thu, 2 Sep 2021 14:11:31 -0700 Message-ID: To: Richard Barnes Cc: sframe@ietf.org Content-Type: multipart/alternative; boundary="00000000000026332805cb09a147" Archived-At: Subject: Re: [Sframe] Negotiating SFrame/RTP in SDP X-BeenThere: sframe@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Secure Media Frames List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Sep 2021 21:11:52 -0000 --00000000000026332805cb09a147 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Thu, Sep 2, 2021 at 13:23 Richard Barnes wrote: > > Personally, I think the proposal in Sergio's draft is a little wide of th= e > mark. ISTM that specifying a "generic" media format and recovering the > specificity in an RTP header is more complex than is needed. Worse, it se= ts > up implementations to send the same media both encrypted and unencrypted = -- > obviously not great for security. > > I'd like to propose a simpler approach, drawing inspiration from cryptex > [3]: > > a=3Dsframe: [] > > Basically, just a new SDP attribute per m-line, that specifies that SFram= e > encryption is being done and how. The desired semantic is clear for SPac= ket > [BA] My assumption is that an a=3D line in the Offer means =E2=80=9CI desir= e to send encrypted media, and can also receive it=E2=80=9D. Is that your understandi= ng? If a corresponding a=3Dline is provided in the Answer does this mean =E2=80=9C= I will send encrypted media and will expect to receive encrypted media=E2=80=9D so= that clear text media won=E2=80=99t be sent in either direction? Is there an expectation that all BUNDLED m lines have the same settings, or can they be different? The desired semantic is clear for SPacket: Just add an SFrame > protect/unprotect > [BA] In the case of BUNDLED media, it may not be quite that simple (e.g. you may have to figure out which packets are supposed to be protected first). The problem is that that constraint is incompatible with Insertable > Streams. So we need to decide how much we care about compatibility with = IS > as it is. > [BA] If we can get clarity on the architecture and the protocol as well as the use cases, then the API(s) will follow. But requiring backwards compatibility with existing Web APIs could be overly constraining (and might yield a null solution set). Personally, it seems like WebRTC stacks and web apps are going to have to > upgrade *anyway* if they're going to support SDP-based negotiation of > SFrame, so if they have to make this one extra change, it shouldn't be a > big deal. > [BA] I would like to suggest broadening the mindset beyond WebRTC. One of the major advantages of SFRAME is that it is transport agnostic, so that it can be transported over WebRTC data channel, WebTransport, or even HTTPS. As a result, WebRTC Encoded Transform is not the only relevant Web API and W3C WEBRTC WG is not the only relevant W3C WG. --00000000000026332805cb09a147 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Thu, Sep 2, 2021 at 13:23 Richard Barnes <rlb@ipv.sx> wrote:

Person= ally, I think the proposal in Sergio's draft is a little wide of the ma= rk.=C2=A0 ISTM that specifying a "generic" media format and recov= ering the specificity in an RTP header is more complex than is needed. Wors= e, it sets up implementations to send the same media both encrypted and une= ncrypted -- obviously not great for security.

I'd like to propos= e a simpler approach, drawing inspiration from cryptex [3]:

a=3Dsfra= me:<frame|packet> [<keying>]

Basically, just a new SDP a= ttribute per m-line, that specifies that SFrame encryption is being done an= d how.=C2=A0 The desired semantic is clear for SPacket

[BA] My assumption is that an a= =3D line in the Offer means =E2=80=9CI desire to send encrypted media, and = can also receive it=E2=80=9D. Is that your understanding?=C2=A0 If a corres= ponding a=3Dline is provided in the Answer does this mean =E2=80=9CI will s= end encrypted media and will expect to receive encrypted media=E2=80=9D so = that clear text media won=E2=80=99t be sent in either direction?=C2=A0 Is t= here an expectation that all BUNDLED m lines have the same settings, or can= they be different? =C2=A0

The desired semantic is clear for SPacket:= Just add an SFrame protect/unprotect=C2=A0

[BA] In the case of BUNDLED media, it may = not be quite that simple (e.g. you may have to figure out which packets are= supposed to be protected first).=C2=A0

The problem is that that cons= traint is incompatible with Insertable Streams.=C2=A0 So we need to decide = how much we care about compatibility with IS as it is.

[BA] If we can get clarity on t= he architecture and the protocol as well as the use cases, then the API(s) = will follow. But requiring backwards compatibility with existing Web APIs c= ould be overly constraining (and might yield a null solution set).

= =C2=A0 Personally, it seems like WebRTC stacks and web apps are going to ha= ve to upgrade *anyway* if they're going to support SDP-based negotiatio= n of SFrame, so if they have to make this one extra change, it shouldn'= t be a big deal.

[BA] I would like to suggest broadening the mindset beyond WebRTC= .=C2=A0 One of the major advantages of SFRAME is that it is transport agnos= tic, so that it can be transported over WebRTC data channel, WebTransport, = or even HTTPS.=C2=A0 As a result, WebRTC Encoded Transform is not the only = relevant Web API and W3C WEBRTC WG is not the only relevant W3C WG.=C2=A0
--00000000000026332805cb09a147-- From nobody Thu Sep 2 16:07:20 2021 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 595B13A16D3 for ; Thu, 2 Sep 2021 16:07:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.101 X-Spam-Level: X-Spam-Status: No, score=-2.101 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=lowentropy.net header.b=gSdcZ/ay; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=mbP5smHO 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 iE-eV7Egc-_K for ; Thu, 2 Sep 2021 16:07:13 -0700 (PDT) Received: from wout5-smtp.messagingengine.com (wout5-smtp.messagingengine.com [64.147.123.21]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6018C3A16D2 for ; Thu, 2 Sep 2021 16:07:13 -0700 (PDT) Received: from compute5.internal (compute5.nyi.internal [10.202.2.45]) by mailout.west.internal (Postfix) with ESMTP id 4127F32009E3 for ; Thu, 2 Sep 2021 19:07:12 -0400 (EDT) Received: from imap41 ([10.202.2.91]) by compute5.internal (MEProxy); Thu, 02 Sep 2021 19:07:12 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lowentropy.net; h=mime-version:message-id:in-reply-to:references:date:from:to :subject:content-type; s=fm3; bh=3egbRK37FpVRjCOkasdDaFpNu5zFs9r NrI4EHHgmy6w=; b=gSdcZ/ay9MjbN7YufyOJr3XoGS1h5Aar8lxuoaKHARKCSMc XlSBqCK/AVhn0lwoN8eRJ0SHmSDINFKeMe60NePH2cAa6YSWCzJA+F1lDGpiaRpl Y1HqRzFS43PTxJwh/4BN0O/KzdRCmet4o67HDxANYyvMTSpLxvdySghv4efWI+DO VKnhTdBZ70Ye9pCpqHNhCSTnnq19DDSBpcwFY5u88coZTQp3h7coUq4XdyirHKF4 vQVyb9AYCfYkpfUKYeZ+IRpL9xlwRSLnt816HJfXWwW6nVbglrUTaSVNaB2VdW6/ /+lwn18pEzH/+39tSqVrEDV6FPsa16+nsMUcMrw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm3; bh=3egbRK 37FpVRjCOkasdDaFpNu5zFs9rNrI4EHHgmy6w=; b=mbP5smHOf12J0uGae/jRC+ qSCV6+CRMiuAPQgP2MF+8KM4hN1mcJtbuzpm+bTvFNr8Ds6/09vGzw2LEi+Z8hGk sKMcZdglTo0mQ7exc6CXMf7r27GDRaTqRepncG2aOHfImdR29C+Gfxorpb1awJ7n kuDqEHLvwsHqNPWG3s3peOWJ00Lpn+6kv+RLBx/wWXrvho0r0sbkIElSvKvDUDGa PhhRx2KQjyuQPWs46segZ1lhfQeu/p3fgl4dLa+9QBcq7/CF5GmLxdrcL61gajHs cW3BfgKmMc5q2e0iHAbW+6Qii+LMzZA1lxOw0cDhYU1vsyVVGCcNaAc9Wlve/qjQ == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvtddruddviedgudelucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpefofgggkfgjfhffhffvufgtsehttd ertderreejnecuhfhrohhmpedfofgrrhhtihhnucfvhhhomhhsohhnfdcuoehmtheslhho figvnhhtrhhophihrdhnvghtqeenucggtffrrghtthgvrhhnpeehfeetudduudehtdekhf dvhfetleffudejgeejffehffevkeduiefgueevkeefleenucevlhhushhtvghrufhiiigv pedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpehmtheslhhofigvnhhtrhhophihrdhnvg ht X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 873D83C0EB6; Thu, 2 Sep 2021 19:07:11 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.5.0-alpha0-1126-g6962059b07-fm-20210901.001-g6962059b Mime-Version: 1.0 Message-Id: <98cb5f86-1d39-4006-b0a3-fc4bb59b7c9a@www.fastmail.com> In-Reply-To: References: Date: Fri, 03 Sep 2021 09:06:51 +1000 From: "Martin Thomson" To: sframe@ietf.org Content-Type: text/plain Archived-At: Subject: Re: [Sframe] =?utf-8?q?Propose_to_adopt_draft-omara-sframe_and_draft?= =?utf-8?q?-barnes-sframe-mls?= X-BeenThere: sframe@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Secure Media Frames List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Sep 2021 23:07:19 -0000 On Fri, Sep 3, 2021, at 06:19, Richard Barnes wrote: > There hasn't been much discussion here on these drafts, but I get the > impression that folks pretty much agree that these drafts should be the > starting points for meeting the WG's milestones. draft-omara-sframe > for the milestone already in the charter, and draft-barnes-sframe-mls > for the milestone implied by the last paragraph. Emad is working on revising the sframe draft. His coauthors probably need to help out. I'd like to have some discussion about the revision before we start the call. From nobody Mon Sep 6 11:54:09 2021 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 02E583A19AF for ; Mon, 6 Sep 2021 11:54:06 -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 uDC8T3OFCXtI for ; Mon, 6 Sep 2021 11:53:57 -0700 (PDT) Received: from mail-pf1-x42c.google.com (mail-pf1-x42c.google.com [IPv6:2607:f8b0:4864:20::42c]) (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 4F9613A1A7E for ; Mon, 6 Sep 2021 11:53:57 -0700 (PDT) Received: by mail-pf1-x42c.google.com with SMTP id q22so1448932pfu.0 for ; Mon, 06 Sep 2021 11:53:57 -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=/0pNaW/5lGX9o5kygs2NJguX3B6lEXtPvmYEQrBoWkg=; b=e3NN9ew38HdpDlq91FBoUtPwiTCLc38A3ZfPs+lLTtF41ywJKesMPMhMxfcEVpDFiW 7s0vqJp4A/OGPSfTU7+v83nd/yH/5wIQ3pg35T9zuPysKJKnkzd8IiuoOr3PZfhTMoOM u3N20NLfn3pdaEOwFHPBDPg2GIRA9dx2Qlda0lcI+s8dK3E/Vzr2KuV2tSoVisFYJdW2 GU2l0VZGg0bFqc73PBDZ4KstZIClgWWvcGoVeeTCnCXkmikCp40b5jv1i8n2NIRJ1Ox1 h3d9EGxygzeZmd28N0R5B9SWHQ2ttz3emzR0g2PDS2EJgYT4HA5q5d1OSIPxG+lSpw86 emgA== 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=/0pNaW/5lGX9o5kygs2NJguX3B6lEXtPvmYEQrBoWkg=; b=az8Gqnrm4UbVHayiZwUSGdj3mL1vGMUIcNzqcukz3E1ZS6X8fqrcZAsNKP4oTNAgNb EWphbTgcrxRgpX2Ebs9QB51rfD1Se70eukueUjUiH7daL19/+OCPY4zF0NmMAYU1k+CV Qj4FYkb0kXSPUbBKO87TnwU2UoZFCVUGoAx7KFULd63FlNgNoFZlEs/3BcY8ZQPuRdk+ bb8UcbIkN2/IEbKfVRStyurdeHOsLkGPasLm5EaaXSSGEHWZQGpSP41zVVwPZq/5EPuk rL7Q4sOwWiKsYvCfK1X3UJ/JULz7zepUVumDj9Ai97gs15Er2JcQCxq/0xdE6P282Li/ Iesg== X-Gm-Message-State: AOAM533YwXbCj7AEOsaFVYBdVNFKQRg7W02xZj6FPBgtRN0+ikFpVhnY 9Q+yHN39X1ipSTogF8osvIgXVULDDf42xa14J4D+9g== X-Google-Smtp-Source: ABdhPJxMRwwyi449DC01xyMm9JRsGKt0mPCoX4pdwXIxgh81lAWnUTSCi66K3MCazTSiuH1FSy5k/d5G1FeXTjjaVx8= X-Received: by 2002:a63:6e02:: with SMTP id j2mr13483423pgc.157.1630954435480; Mon, 06 Sep 2021 11:53:55 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Sergio Garcia Murillo Date: Mon, 6 Sep 2021 20:53:44 +0200 Message-ID: To: Richard Barnes Cc: sframe@ietf.org Content-Type: multipart/alternative; boundary="000000000000c5a49705cb582b1e" Archived-At: Subject: Re: [Sframe] Proposal: SFrame && SPacket && !SIDU X-BeenThere: sframe@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Secure Media Frames List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Sep 2021 18:54:07 -0000 --000000000000c5a49705cb582b1e Content-Type: text/plain; charset="UTF-8" Hi Richard, Just one minor comment, the "media frames", should be spatial frames if SVC is used so an SFU is able to not forward all spatial layers to the receiver. Apart from that, I am ok with removing "SIDUs" from the scope. Best regards Sergio On Thu, Sep 2, 2021 at 10:20 PM Richard Barnes wrote: > Hi folks, > > I'd like to see if we can agree to limit our scope a bit. There has been > discussion of multiple levels at which SFrame could be applied: > > * "SFrame" - Whole media frames > * "SPacket" - Individual RTP media payloads > * "SIDU" - Some codec-specific "independently decodeable units" > > I'd like to propose that we take "SIDU" off of the table, but keep the > other two. > > It seems like SFrame and SPacket both have strengths in certain scenarios > (depending on how you want to trade off bandwidth vs. complexity), but > they're both pretty straightforward in terms of how they integrate with the > media processing pipeline. In particular, they don't have any > codec-dependence. SIDU, by contrast, seems like a world of pain. It > requires that the encryption scheme be entangled with the codec, which > requires special per-codec integration logic in the specifications. And > the bandwidth gains for all that complexity are not that large. > > Is there anyone here who feels that SIDU is something this group needs to > spend time specifying? > > --Richard > -- > Sframe mailing list > Sframe@ietf.org > https://www.ietf.org/mailman/listinfo/sframe > --000000000000c5a49705cb582b1e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Richard,

Just one minor comment, the= "media frames", should be spatial frames if SVC is used so an SF= U is able to not forward all spatial layers to the receiver. Apart from tha= t, I am ok with removing "SIDUs"=C2=A0from the scope.
<= br>
Best regards
Sergio

On Thu, Sep 2, 2021 at 10:= 20 PM Richard Barnes <rlb@ipv.sx> w= rote:
Hi folks,

I'd like to see if we can agree to limit our = scope a bit.=C2=A0 There has been discussion of multiple levels at which SF= rame could be applied:

* "SFrame" - Whole media frames
= * "SPacket" - Individual RTP media payloads
* "SIDU"= - Some codec-specific "independently decodeable units"

I&= #39;d like to propose that we take "SIDU" off of the table, but k= eep the other two.

It seems like SFrame and SPacket both have streng= ths in certain scenarios (depending on how you want to trade off bandwidth = vs. complexity), but they're both pretty straightforward in terms of ho= w they integrate with the media processing pipeline.=C2=A0 In particular, t= hey don't have any codec-dependence.=C2=A0 SIDU, by contrast, seems lik= e a world of pain.=C2=A0 It requires that the encryption scheme be entangle= d with the codec, which requires special per-codec integration logic in the= specifications.=C2=A0 And the bandwidth gains for all that complexity are = not that large.

Is there anyone here who feels that SIDU is somethin= g this group needs to spend time specifying?

--Richard
--
Sframe mailing list
Sframe@ietf.org https://www.ietf.org/mailman/listinfo/sframe
--000000000000c5a49705cb582b1e-- From nobody Mon Sep 6 12:14:24 2021 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 70F1E3A1ACF for ; Mon, 6 Sep 2021 12:14:22 -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 6O86XTVmrrO2 for ; Mon, 6 Sep 2021 12:14:17 -0700 (PDT) Received: from mail-pg1-x535.google.com (mail-pg1-x535.google.com [IPv6:2607:f8b0:4864:20::535]) (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 0559E3A15C9 for ; Mon, 6 Sep 2021 12:14:12 -0700 (PDT) Received: by mail-pg1-x535.google.com with SMTP id e7so7638866pgk.2 for ; Mon, 06 Sep 2021 12:14:12 -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=rJPFDKU6zjox7LvgiAmAQgXB90Qj4u1BPoeirhmwOCI=; b=iRkpgqOjQEecI70Y+5qEmo5wUI8Kqi5GuIDbpIYWXTQ18OBqYB5kERv36+yjtNO/AQ AOVkpEyiG9VJdI5DmRNCNUa1QrQmHejxASLFv5K/aPthBqIG7zLMRaAGvN0DpWsGv6I8 mxPNFN0POwmZXozaiurNvovvQ7r7eOA9io/dIARaTZBRAlLZ+WzOEiAQzUW/+8M35+qT VRCV8UuECJLGMtx3f1n63c23cRddYUrgECztGNbn9JubpQE6hGQTsGJeeU7nYFnm+VCL VKbRaTpE3ZR6msKGphdG1Ni/Z7Ti+K5nFjbPPHwxJF2rNiqiqYfQ8+FG42UUOcMRftHw D++Q== 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=rJPFDKU6zjox7LvgiAmAQgXB90Qj4u1BPoeirhmwOCI=; b=ZM/5/te2l0HVD5OVV+1nSav7XpVCcOK8doaXB1f9Gjk2dieWad0T7WJrYmVJAqitAu lu/8EkRDISIr008V2SL+NmrOQgx25YzdskVXnryvkAYHN2G+HZoQ0Js5EXr6GFpKu4EX CYdNVogjHBG5qYsXttPsn0cDMh1UGwJm32AbO8pN5fKV2+jEosVarWwjOMn1FA6Hua6i 6iBejzAqh9HdmW37vmxkCRRJwye0VlgSQRbh0EQ9YnGE4w2c9CHSc4bZdtPlzf+REO7B c1vsUbtAmHehqlEldeH54zYgGUI9EeQScT6Nvw1mErbH/FqjGVVKF790dg5oxbRc5Zli v9PQ== X-Gm-Message-State: AOAM5330xZ34WcWo1XidBekTSn7CW06dVU+FxduLTaVYXgrif60A9R76 8leQ5ls2G0KAArTBBRb3lwj7Ow6J76M1onBt+dzMSrXLCRo= X-Google-Smtp-Source: ABdhPJwCVdihgLJIJ+s+ZKZ2Kouy3wFrboA/VgTMU2T9fgvYo6I3Xrt5PZ/I+3ZhWafpCL8NtNzscsXQSpCgTnBRmgw= X-Received: by 2002:a63:6e02:: with SMTP id j2mr13547279pgc.157.1630955651375; Mon, 06 Sep 2021 12:14:11 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Sergio Garcia Murillo Date: Mon, 6 Sep 2021 21:14:00 +0200 Message-ID: To: Richard Barnes Cc: sframe@ietf.org Content-Type: multipart/alternative; boundary="0000000000003eb3cf05cb587402" Archived-At: Subject: Re: [Sframe] Negotiating SFrame/RTP in SDP X-BeenThere: sframe@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Secure Media Frames List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Sep 2021 19:14:23 -0000 --0000000000003eb3cf05cb587402 Content-Type: text/plain; charset="UTF-8" >From my point of view, all the mechanisms described on the multi codec payload format are required: The ability to differentiate a RTP packet encrypted end to end (either by SFrame or SPacket) is a must, both from a formal point of view about how RTP works, but also to ensure that the media servers does not perform any payload inspection that will cause malfunction (metadata gathering, layer switching, recording..) The optionality of the encryption also comes from various factors. First, end to end encryption is an "endpoint" decision, the SDP negotiation with the media server should not be the place to enforce it or not. Also, not always the media server and the endpoints are provided by the same company (i.e. CPaaS) and they will have to support both end to end encryption and non end to end encryption calls. Note that it is quite a common practice in SFUs to send an SDP offer from the media server to the endpoint, in which case, the media server will have to offer e2e encryption as optional. As an example, in Millicast we support both e2ee and non-e2ee streams today (with the insertable stream per codec hacks), it is a completely optional feature up to each customer to implement and to decide when and if it is used. We are just carriers, and we do not want the customer to have to configure if the stream is e2ee or not. We are not (and must not be) involved in enforcing e2ee in any way. Best regards Sergio On Thu, Sep 2, 2021 at 10:23 PM Richard Barnes wrote: > Hi folks, > > One of the major work items left around SFrame is the work to specify how > SFrame-encrypted media are carried in RTP, and how that is signaled in > SDP. The finer points might need to be worked out in AVTCORE / MMUSIC, but > since this group knows the intricacies better, it seems like having some > agreement here on general approach would be good. > > Sergio put together a first stab at this in > draft-murillo-avtcore-multi-codec-payload-format [1]. He presented this at > AVTCORE @ IETF 111 [2]. Unfortunately, the discussion there doesn't seem > to have provided a clear path forward, thus this thread. > > Personally, I think the proposal in Sergio's draft is a little wide of the > mark. ISTM that specifying a "generic" media format and recovering the > specificity in an RTP header is more complex than is needed. Worse, it sets > up implementations to send the same media both encrypted and unencrypted -- > obviously not great for security. > > I'd like to propose a simpler approach, drawing inspiration from cryptex > [3]: > > a=sframe: [] > > Basically, just a new SDP attribute per m-line, that specifies that SFrame > encryption is being done and how. The desired semantic is clear for > SPacket: Just add an SFrame protect/unprotect before you do other > processing on the media payload. Then you will have a payload that is as > described in the SDP. > > You can *almost* describe SFrame in this way as well. Assemble all the > RTP packets in a frame, then do SFrame across all of their payloads (in > particular, adding the header to the first packet and the tag to the > last). If you constrained the sender to construct pre-SFrame packets that > were properly packetized according to the rest of the SDP, then this would > integrate cleanly with the rest of the SDP/RTP model. The problem is that > that constraint is incompatible with Insertable Streams. So we need to > decide how much we care about compatibility with IS as it is. Personally, > it seems like WebRTC stacks and web apps are going to have to upgrade > *anyway* if they're going to support SDP-based negotiation of SFrame, so if > they have to make this one extra change, it shouldn't be a big deal. > > How does this approach strike folks? > > --Richard > > [1] > https://www.ietf.org/archive/id/draft-murillo-avtcore-multi-codec-payload-format-01.html > [2] https://youtu.be/S-JR4Fa8VFY?t=3510 > [3] > https://www.ietf.org/archive/id/draft-ietf-avtcore-cryptex-02.html#name-signaling > -- > Sframe mailing list > Sframe@ietf.org > https://www.ietf.org/mailman/listinfo/sframe > --0000000000003eb3cf05cb587402 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
From my point of view, all the mechanisms described o= n the multi codec payload format are required:

The= ability to differentiate a RTP packet encrypted end to end (either by SFra= me or SPacket) is a must, both from a formal point of view about how RTP wo= rks, but also to ensure that the media servers does not perform any payload= inspection that will cause malfunction (metadata gathering, layer switchin= g, recording..)=C2=A0

The optionality of the encry= ption also comes from various factors. First, end to end encryption is an &= quot;endpoint" decision, the SDP negotiation with the media server sho= uld not be the place to enforce it or not. Also, not always the media serve= r and the endpoints are provided by the same company (i.e. CPaaS) and they = will have to support both end to end encryption and non end to end encrypti= on calls. Note that it is quite a common practice in SFUs to send an SDP of= fer from the media server to the endpoint, in which case, the media server = will have to offer e2e encryption as optional.

As = an example, in Millicast we support both e2ee and non-e2ee streams today (w= ith the insertable stream per codec hacks), it is a completely=C2=A0optiona= l feature up to each customer to implement and to decide when and if it is = used. We are just carriers, and we do not=C2=A0want the customer to have to= configure if the stream is e2ee or not. We are not (and must not be) invol= ved in enforcing e2ee in any way.=C2=A0

Best regar= ds
Sergio

On Thu, Sep 2, 2021 at 10:23 PM Richard Barnes <rlb@ipv.sx> wrote:
Hi folks,

One of= the major work items left around SFrame is the work to specify how SFrame-= encrypted media are carried in RTP, and how that is signaled in SDP.=C2=A0 = The finer points might need to be worked out in AVTCORE / MMUSIC, but since= this group knows the intricacies better, it seems like having some agreeme= nt here on general approach would be good.

Sergio put together a fir= st stab at this in draft-murillo-avtcore-multi-codec-payload-format [1].=C2= =A0 He presented this at AVTCORE @ IETF 111 [2].=C2=A0 Unfortunately, the d= iscussion there doesn't seem to have provided a clear path forward, thu= s this thread.

Personally, I think the proposal in Sergio's draf= t is a little wide of the mark.=C2=A0 ISTM that specifying a "generic&= quot; media format and recovering the specificity in an RTP header is more = complex than is needed. Worse, it sets up implementations to send the same = media both encrypted and unencrypted -- obviously not great for security.
I'd like to propose a simpler approach, drawing inspiration from = cryptex [3]:

a=3Dsframe:<frame|packet> [<keying>]
Basically, just a new SDP attribute per m-line, that specifies that SFrame= encryption is being done and how.=C2=A0 The desired semantic is clear for = SPacket: Just add an SFrame protect/unprotect before you do other processin= g on the media payload.=C2=A0 Then you will have a payload that is as descr= ibed in the SDP.

You can *almost* describe SFrame in this way as wel= l.=C2=A0 Assemble all the RTP packets in a frame, then do SFrame across all= of their payloads (in particular, adding the header to the first packet an= d the tag to the last).=C2=A0 If you constrained the sender to construct pr= e-SFrame packets =C2=A0that were properly packetized according to the rest = of the SDP, then this would integrate cleanly with the rest of the SDP/RTP = model.=C2=A0 The problem is that that constraint is incompatible with Inser= table Streams.=C2=A0 So we need to decide how much we care about compatibil= ity with IS as it is.=C2=A0 Personally, it seems like WebRTC stacks and web= apps are going to have to upgrade *anyway* if they're going to support= SDP-based negotiation of SFrame, so if they have to make this one extra ch= ange, it shouldn't be a big deal.

How does this approach strike = folks?

--Richard

[1] https://www.ietf.org/archive/id/draft-murillo-avtcore-multi-codec-paylo= ad-format-01.html
[2] https://youtu.be/S-JR4Fa8VFY?t=3D3510
[3] https://www.ietf.org/archive/id/draft-ietf= -avtcore-cryptex-02.html#name-signaling
--
Sframe mailing list
Sframe@ietf.org https://www.ietf.org/mailman/listinfo/sframe
--0000000000003eb3cf05cb587402-- From nobody Mon Sep 6 16:39:52 2021 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 22FE83A0AE0 for ; Mon, 6 Sep 2021 16:39:50 -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 T_w0JlkcB1qS for ; Mon, 6 Sep 2021 16:39:45 -0700 (PDT) Received: from mail-lf1-x131.google.com (mail-lf1-x131.google.com [IPv6:2a00:1450:4864:20::131]) (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 C7F543A0ADE for ; Mon, 6 Sep 2021 16:39:44 -0700 (PDT) Received: by mail-lf1-x131.google.com with SMTP id x27so15940329lfu.5 for ; Mon, 06 Sep 2021 16:39:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=+py9CRhaIoHr5LKnfueFa5OXoxDAacngrhHuRNTb8Ag=; b=eMleM8Pc/arfNQs5MTcu0H8AMviB2DJN0DfZgmBS5aBPXOoeb5MLU9g7wty4bqNND4 CpW5B3vM0y1u5g8efrT9/J9JTY2F8ZAkJhHTSW6rEiXg6LjOcmgXtf/5Y7MticKRGpuG ZbPSIxYgLJ1OhNLQoMDWH1y/TQBVN1BuCTvEachuY4Bik86DuzPfrKo3XVBFEHPtxzWI fbecY6vI7JfwOx+/rQeIgZn3ui6RahJNPXn/wy9QDTmRCXfkShb4bTCcW3gJ6rl9tBLT 3hGzA8OhtbNjDGm3p7fPN1GXIOPBhDiqbeJhEAk83L564D97niYQebvzaWbgN0gTij6k NkYQ== 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=+py9CRhaIoHr5LKnfueFa5OXoxDAacngrhHuRNTb8Ag=; b=BYeUebEPt3WZoJiF8TLGqeTsXj3oKkUA7Otxrfyep4SW/pKsj91uHW88yMk84EcPOy 9S5yRe/gDwTUzf3hO+yc4/9uPMSZnfnAehHTJmrZ82DtOu74Zw9EI0gbeauvLi5/3ap8 T8eOxqSxZgVRI0hG+LplSju/+Oo89x3aOa+q/NtikoOaPk9FO8KYZPkqGw5In14kCaaJ mzoTF1Cxhyrs6iWr8KgFEzraAg+thi3SBSKp6PNyEd/pO6MgnjU8C1jJeRwLmsoU8Ltv 1OMw6VFp/9qat8lTq3yvXJryI/V4d5GOZ4gEaqEYll5yDZTQwgKhPaBET9d+lL0pXyWG L7pg== X-Gm-Message-State: AOAM533ZOjpsXqKWb90PI3fk8F9QiE66xNh2bdIUL3rbecVXCGPl1gjv Ll6+co/tKmmK+G0c0spWHiCTUoi+K5SJVes2ZRCYEcT2GxM= X-Google-Smtp-Source: ABdhPJxGBw1vbHK205CHwKzKQWxZ6VFr2Prr/6uy7otbatb8JWcPnZVcVV0tPm+iri+t/5Cb5mhb5HkQ9JckkgFoLBI= X-Received: by 2002:a05:6512:3a95:: with SMTP id q21mr10718461lfu.198.1630971580883; Mon, 06 Sep 2021 16:39:40 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Bernard Aboba Date: Mon, 6 Sep 2021 16:39:30 -0700 Message-ID: To: Sergio Garcia Murillo Cc: Richard Barnes , sframe@ietf.org Content-Type: multipart/alternative; boundary="000000000000b7a79c05cb5c294d" Archived-At: Subject: Re: [Sframe] Negotiating SFrame/RTP in SDP X-BeenThere: sframe@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Secure Media Frames List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Sep 2021 23:39:50 -0000 --000000000000b7a79c05cb5c294d Content-Type: text/plain; charset="UTF-8" Richard said: "Just add an SFrame protect/unprotect before you do other processing on the media payload. Then you will have a payload that is as described in the SDP." [BA] If the SFU is untrusted to have cleartext access to the payload, why would the endpoint use SDP to negotiate with the SFU whether to use E2E encryption? This potentially enables a downgrade attack. Such a negotiation only makes sense in a use case where there are some clients that support E2E encryption and others that do not, and the SFU is looking to gracefully keep the non-E2E endpoints out of the conference (e.g. by failing the O/A negotiation, instead of succeeding and then having the non-E2E endpoints being unable to parse the codec payloads). Sergio said: "Also, not always the media server and the endpoints are provided by the same company (i.e. CPaaS) and they will have to support both end to end encryption and non end to end encryption calls. " [BA] SDP negotiation between the endpoint and SFU is useful in negotiating hop-by-hop parameters, such as the RTP header extensions needed by the SFU to forward packets without inspecting the RTP payload. But in a CPaaS scenario, I agree that the application will determine whether to use E2E encryption or not and the SFU need not know or care, since it isn't parsing the codec payloads anyway. In that scenario you won't have a mixture of E2E capable and non-capable endpoints, so the SDP negotiation would serve no useful purpose. On Mon, Sep 6, 2021 at 12:14 PM Sergio Garcia Murillo < sergio.garcia.murillo@cosmosoftware.io> wrote: > From my point of view, all the mechanisms described on the multi codec > payload format are required: > > The ability to differentiate a RTP packet encrypted end to end (either by > SFrame or SPacket) is a must, both from a formal point of view about how > RTP works, but also to ensure that the media servers does not perform any > payload inspection that will cause malfunction (metadata gathering, layer > switching, recording..) > > The optionality of the encryption also comes from various factors. First, > end to end encryption is an "endpoint" decision, the SDP negotiation with > the media server should not be the place to enforce it or not. Also, not > always the media server and the endpoints are provided by the same company > (i.e. CPaaS) and they will have to support both end to end encryption and > non end to end encryption calls. Note that it is quite a common practice in > SFUs to send an SDP offer from the media server to the endpoint, in which > case, the media server will have to offer e2e encryption as optional. > > As an example, in Millicast we support both e2ee and non-e2ee streams > today (with the insertable stream per codec hacks), it is a > completely optional feature up to each customer to implement and to decide > when and if it is used. We are just carriers, and we do not want the > customer to have to configure if the stream is e2ee or not. We are not (and > must not be) involved in enforcing e2ee in any way. > > Best regards > Sergio > > On Thu, Sep 2, 2021 at 10:23 PM Richard Barnes wrote: > >> Hi folks, >> >> One of the major work items left around SFrame is the work to specify how >> SFrame-encrypted media are carried in RTP, and how that is signaled in >> SDP. The finer points might need to be worked out in AVTCORE / MMUSIC, but >> since this group knows the intricacies better, it seems like having some >> agreement here on general approach would be good. >> >> Sergio put together a first stab at this in >> draft-murillo-avtcore-multi-codec-payload-format [1]. He presented this at >> AVTCORE @ IETF 111 [2]. Unfortunately, the discussion there doesn't seem >> to have provided a clear path forward, thus this thread. >> >> Personally, I think the proposal in Sergio's draft is a little wide of >> the mark. ISTM that specifying a "generic" media format and recovering the >> specificity in an RTP header is more complex than is needed. Worse, it sets >> up implementations to send the same media both encrypted and unencrypted -- >> obviously not great for security. >> >> I'd like to propose a simpler approach, drawing inspiration from cryptex >> [3]: >> >> a=sframe: [] >> >> Basically, just a new SDP attribute per m-line, that specifies that >> SFrame encryption is being done and how. The desired semantic is clear for >> SPacket: Just add an SFrame protect/unprotect before you do other >> processing on the media payload. Then you will have a payload that is as >> described in the SDP. >> >> You can *almost* describe SFrame in this way as well. Assemble all the >> RTP packets in a frame, then do SFrame across all of their payloads (in >> particular, adding the header to the first packet and the tag to the >> last). If you constrained the sender to construct pre-SFrame packets that >> were properly packetized according to the rest of the SDP, then this would >> integrate cleanly with the rest of the SDP/RTP model. The problem is that >> that constraint is incompatible with Insertable Streams. So we need to >> decide how much we care about compatibility with IS as it is. Personally, >> it seems like WebRTC stacks and web apps are going to have to upgrade >> *anyway* if they're going to support SDP-based negotiation of SFrame, so if >> they have to make this one extra change, it shouldn't be a big deal. >> >> How does this approach strike folks? >> >> --Richard >> >> [1] >> https://www.ietf.org/archive/id/draft-murillo-avtcore-multi-codec-payload-format-01.html >> [2] https://youtu.be/S-JR4Fa8VFY?t=3510 >> [3] >> https://www.ietf.org/archive/id/draft-ietf-avtcore-cryptex-02.html#name-signaling >> -- >> Sframe mailing list >> Sframe@ietf.org >> https://www.ietf.org/mailman/listinfo/sframe >> > -- > Sframe mailing list > Sframe@ietf.org > https://www.ietf.org/mailman/listinfo/sframe > --000000000000b7a79c05cb5c294d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Richard said:=C2=A0

"Just add an S= Frame protect/unprotect before you do other processing on the media payload= .=C2=A0 Then you will have a payload that is as described in the SDP."=

[BA]=C2=A0 If the SFU is untrusted to have cleart= ext access to the payload, why would the endpoint use SDP to negotiate with= the SFU whether to use E2E encryption?=C2=A0 This potentially enables a do= wngrade attack.=C2=A0=C2=A0

Such a negotiation onl= y makes sense in a use case where there are=C2=A0some clients that support = E2E encryption and others that do not, and the SFU is looking to gracefully= keep the non-E2E endpoints out of the conference (e.g. by failing the O/A = negotiation, instead of succeeding and then having the non-E2E endpoints be= ing unable=C2=A0to parse the codec payloads).=C2=A0

Sergio said:=C2=A0

"Also, not always the media se= rver and the endpoints are provided by the same company (i.e. CPaaS) and th= ey will have to support both end to end encryption and non end to end encry= ption calls. "

[BA]=C2=A0 SDP negotiation bet= ween the endpoint and SFU is useful in negotiating hop-by-hop parameters, s= uch as the RTP header extensions needed by the SFU to forward packets witho= ut inspecting the RTP payload.=C2=A0=C2=A0

But in = a CPaaS scenario, I agree that the application will determine whether to us= e E2E encryption or not and the SFU need not know or care, since it isn'= ;t parsing the codec payloads anyway.=C2=A0 In that scenario you won't = have a mixture of E2E capable and non-capable endpoints, so the SDP negotia= tion would serve no useful purpose.



On Mon, Sep 6, 2021 at 12:14 PM Sergio Garcia Murillo <sergio.garcia.= murillo@cosmosoftware.io> wrote:
From my point of view, all th= e mechanisms described on the multi codec payload format are required:

The ability to differentiate a RTP packet encrypted en= d to end (either by SFrame or SPacket) is a must, both from a formal point = of view about how RTP works, but also to ensure that the media servers does= not perform any payload inspection that will cause malfunction (metadata g= athering, layer switching, recording..)=C2=A0

The = optionality of the encryption also comes from various factors. First, end t= o end encryption is an "endpoint" decision, the SDP negotiation w= ith the media server should not be the place to enforce it or not. Also, no= t always the media server and the endpoints are provided by the same compan= y (i.e. CPaaS) and they will have to support both end to end encryption and= non end to end encryption calls. Note that it is quite a common practice i= n SFUs to send an SDP offer from the media server to the endpoint, in which= case, the media server will have to offer e2e encryption as optional.

As an example, in Millicast we support both e2ee and n= on-e2ee streams today (with the insertable stream per codec hacks), it is a= completely=C2=A0optional feature up to each customer to implement and to d= ecide when and if it is used. We are just carriers, and we do not=C2=A0want= the customer to have to configure if the stream is e2ee or not. We are not= (and must not be) involved in enforcing e2ee in any way.=C2=A0
<= br>
Best regards
Sergio

On Thu, Sep 2, 2021 at 10:23 PM = Richard Barnes <rlb@ipv.= sx> wrote:
Hi folks,

One of the major work items left around= SFrame is the work to specify how SFrame-encrypted media are carried in RT= P, and how that is signaled in SDP.=C2=A0 The finer points might need to be= worked out in AVTCORE / MMUSIC, but since this group knows the intricacies= better, it seems like having some agreement here on general approach would= be good.

Sergio put together a first stab at this in draft-murillo-= avtcore-multi-codec-payload-format [1].=C2=A0 He presented this at AVTCORE = @ IETF 111 [2].=C2=A0 Unfortunately, the discussion there doesn't seem = to have provided a clear path forward, thus this thread.

Personally,= I think the proposal in Sergio's draft is a little wide of the mark.= =C2=A0 ISTM that specifying a "generic" media format and recoveri= ng the specificity in an RTP header is more complex than is needed. Worse, = it sets up implementations to send the same media both encrypted and unencr= ypted -- obviously not great for security.

I'd like to propose a= simpler approach, drawing inspiration from cryptex [3]:

a=3Dsframe:= <frame|packet> [<keying>]

Basically, just a new SDP attr= ibute per m-line, that specifies that SFrame encryption is being done and h= ow.=C2=A0 The desired semantic is clear for SPacket: Just add an SFrame pro= tect/unprotect before you do other processing on the media payload.=C2=A0 T= hen you will have a payload that is as described in the SDP.

You can= *almost* describe SFrame in this way as well.=C2=A0 Assemble all the RTP p= ackets in a frame, then do SFrame across all of their payloads (in particul= ar, adding the header to the first packet and the tag to the last).=C2=A0 I= f you constrained the sender to construct pre-SFrame packets =C2=A0that wer= e properly packetized according to the rest of the SDP, then this would int= egrate cleanly with the rest of the SDP/RTP model.=C2=A0 The problem is tha= t that constraint is incompatible with Insertable Streams.=C2=A0 So we need= to decide how much we care about compatibility with IS as it is.=C2=A0 Per= sonally, it seems like WebRTC stacks and web apps are going to have to upgr= ade *anyway* if they're going to support SDP-based negotiation of SFram= e, so if they have to make this one extra change, it shouldn't be a big= deal.

How does this approach strike folks?

--Richard

= [1] https://www.ietf.org/archiv= e/id/draft-murillo-avtcore-multi-codec-payload-format-01.html
[2] https://y= outu.be/S-JR4Fa8VFY?t=3D3510
[3] https://www.ietf.org/archive/id/draft-ietf-avtcore-cryptex-02.html#name-s= ignaling
--
Sframe mailing list
Sframe@ietf.org https://www.ietf.org/mailman/listinfo/sframe
--
Sframe mailing list
Sframe@ietf.org https://www.ietf.org/mailman/listinfo/sframe
--000000000000b7a79c05cb5c294d-- From nobody Tue Sep 7 12:46:24 2021 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 05DDA3A11F7 for ; Tue, 7 Sep 2021 12:46:22 -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 c7Ltfuqwe60z for ; Tue, 7 Sep 2021 12:46:16 -0700 (PDT) Received: from mail-qk1-x72e.google.com (mail-qk1-x72e.google.com [IPv6:2607:f8b0:4864:20::72e]) (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 68DF63A11F5 for ; Tue, 7 Sep 2021 12:46:16 -0700 (PDT) Received: by mail-qk1-x72e.google.com with SMTP id f22so128894qkm.5 for ; Tue, 07 Sep 2021 12:46:16 -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=+Kv8tfoiJl3mam66pZsi4ltEo00wcS0m3790BBCPmK8=; b=rg+oUjbx7Ir+rLEF7XHnH71zuaCNV/sQytd96MI8QnvQqO2DKOi357A95cvcMFg42v 8iqKP6bAgNrleXoM2fJG2ufmy2dWbu0iSkUsAN3Ypd7lHYJ0znWDTOsLQ4LK3fIIAUgB eTaBAEIwkYuHV4/A1n1snRYUG6AkDJIdhuQcg0WC6D6nMVIcmnSKDotC2KepEzfiLfY0 3ktW+60aPH7GxkDMob6Pdz6AvvFdgSOSasbTQ31XNzOK3lfFG256i7MuAwB8cw4RGrzh w5cKCe+EVubit3lDRHEP7KPLtZSKGSjp36MaKkV0zNNfUnGWKeij/uWAY5GXItb2urdd lr5w== 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=+Kv8tfoiJl3mam66pZsi4ltEo00wcS0m3790BBCPmK8=; b=s7iuqzggO7q3bOW/3JkNUeiA03tWAkxxCLgthj9FBz+esdJcmHVeg4BYIuv52x/UX7 cYSUEWTh0K9EP5zSe8Hlz0OiYZbb8N/AKAZ6DgLZ+N7a9s4ktQ1lugjqHmkWgzw+HdIE R+07GgYefF//f+raa8ZmePMjCYFsh+y+W+jIGntRB1s1NyN01PKhoA+FmFeqfv9Szwlc 0X3OmYeVBpCX94+M6ggLN2qFZv4+QuhnhXhqALOgIfEfjzF0GLTOg3io9uhMJUiiI6mY JCjB5BFmnwuRNQCFmPLnzQPbA+RNJGv8wvWj84xuLTCGGU6s+FFr830Q+8HJKIZYTwPz 7suQ== X-Gm-Message-State: AOAM53246kh82efNlKI71h8mCPkdLXXo8OonMWhAXhWGQg2v+V4tPVas Ota4x4lAhsVHgg/7c5OnMNHe11p4aBmMLybyzfzhuQ== X-Google-Smtp-Source: ABdhPJyHz7ZDg5i3LhAVcwkRyuD6D6HQ+Qlx1zV4wBvNKPPg1EXknZYbJ6nhQ2QGKxDWw9thCyAkEWyyuMx8Q/JcDHs= X-Received: by 2002:ae9:f701:: with SMTP id s1mr17659434qkg.223.1631043974271; Tue, 07 Sep 2021 12:46:14 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Richard Barnes Date: Tue, 7 Sep 2021 15:46:02 -0400 Message-ID: To: Sergio Garcia Murillo Cc: sframe@ietf.org Content-Type: multipart/alternative; boundary="000000000000b32a7505cb6d0427" Archived-At: Subject: Re: [Sframe] Proposal: SFrame && SPacket && !SIDU X-BeenThere: sframe@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Secure Media Frames List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Sep 2021 19:46:22 -0000 --000000000000b32a7505cb6d0427 Content-Type: text/plain; charset="UTF-8" I'm not totally sure what you mean by "spatial frames" here; looks like the notion varies some by codec. Assuming "spatial frames" are frames in the sense of "something that comes out of depacketizater", I think we're probably on the same page. Maybe it would be clearer to state the proposal as: Encryption is done in units of whole RTP payloads. One payload for SPacket; all payloads in the frame for SFrame. We would not support cases where an encrypted unit would span a partial RTP payload. For example: NOT OK Payload 1: First part of SFrame unit A Payload 2: Second part of A, first part of B Payload 3: Second part of B OK Payload 1: SFrame unit A Payload 2: First part of Sframe unit B Payload 3: Second part of B Does that line up with what you have in mind? --Richard On Mon, Sep 6, 2021 at 2:53 PM Sergio Garcia Murillo < sergio.garcia.murillo@cosmosoftware.io> wrote: > Hi Richard, > > Just one minor comment, the "media frames", should be spatial frames if > SVC is used so an SFU is able to not forward all spatial layers to the > receiver. Apart from that, I am ok with removing "SIDUs" from the scope. > > Best regards > Sergio > > On Thu, Sep 2, 2021 at 10:20 PM Richard Barnes wrote: > >> Hi folks, >> >> I'd like to see if we can agree to limit our scope a bit. There has been >> discussion of multiple levels at which SFrame could be applied: >> >> * "SFrame" - Whole media frames >> * "SPacket" - Individual RTP media payloads >> * "SIDU" - Some codec-specific "independently decodeable units" >> >> I'd like to propose that we take "SIDU" off of the table, but keep the >> other two. >> >> It seems like SFrame and SPacket both have strengths in certain scenarios >> (depending on how you want to trade off bandwidth vs. complexity), but >> they're both pretty straightforward in terms of how they integrate with the >> media processing pipeline. In particular, they don't have any >> codec-dependence. SIDU, by contrast, seems like a world of pain. It >> requires that the encryption scheme be entangled with the codec, which >> requires special per-codec integration logic in the specifications. And >> the bandwidth gains for all that complexity are not that large. >> >> Is there anyone here who feels that SIDU is something this group needs to >> spend time specifying? >> >> --Richard >> -- >> Sframe mailing list >> Sframe@ietf.org >> https://www.ietf.org/mailman/listinfo/sframe >> > --000000000000b32a7505cb6d0427 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I'm not totally sure what you mean by "spati= al frames" here; looks like the notion varies some by codec.=C2=A0 Ass= uming "spatial frames" are frames in the sense of "something= that comes out of depacketizater", I think we're probably on the = same page.

Maybe it would be clearer to state the = proposal as: Encryption is done in units of whole RTP payloads.=C2=A0 One p= ayload for SPacket; all payloads in the frame for SFrame.=C2=A0 We would no= t support cases where an encrypted unit would span a partial RTP payload.= =C2=A0 For example:

NOT OK
Paylo= ad 1: First part of SFrame unit A
Payload 2: Second part of A= , first part of B
Payload 3: Second part of B

OK
Payload 1: SFrame unit A
Payload 2: First = part of Sframe unit B
Payload 3: Second part of B

Does that line up with what you have in mind?

--Richard

On Mon, Sep 6, 2021 at 2:53 PM Sergio Garcia Muri= llo <sergio.ga= rcia.murillo@cosmosoftware.io> wrote:
Hi Richard,

Just one minor comment, the "media frames", should be spatial f= rames if SVC is used so an SFU is able to not forward all spatial layers to= the receiver. Apart from that, I am ok with removing "SIDUs"=C2= =A0from the scope.

Best regards
Sergio

On Thu, Sep 2, 2021 at 10:20 PM Richard Barnes <rlb@ipv.sx> wrote:
Hi folks,

I&#= 39;d like to see if we can agree to limit our scope a bit.=C2=A0 There has = been discussion of multiple levels at which SFrame could be applied:
* "SFrame" - Whole media frames
* "SPacket" - Indiv= idual RTP media payloads
* "SIDU" - Some codec-specific "= independently decodeable units"

I'd like to propose that we= take "SIDU" off of the table, but keep the other two.

It = seems like SFrame and SPacket both have strengths in certain scenarios (dep= ending on how you want to trade off bandwidth vs. complexity), but they'= ;re both pretty straightforward in terms of how they integrate with the med= ia processing pipeline.=C2=A0 In particular, they don't have any codec-= dependence.=C2=A0 SIDU, by contrast, seems like a world of pain.=C2=A0 It r= equires that the encryption scheme be entangled with the codec, which requi= res special per-codec integration logic in the specifications.=C2=A0 And th= e bandwidth gains for all that complexity are not that large.

Is the= re anyone here who feels that SIDU is something this group needs to spend t= ime specifying?

--Richard
--
Sframe mailing list
Sframe@ietf.org https://www.ietf.org/mailman/listinfo/sframe
--000000000000b32a7505cb6d0427-- From nobody Thu Sep 9 11:49:51 2021 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 769743A0CBE for ; Thu, 9 Sep 2021 11:49:49 -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 raao7YWaVPDD for ; Thu, 9 Sep 2021 11:49:44 -0700 (PDT) Received: from mail-qk1-x736.google.com (mail-qk1-x736.google.com [IPv6:2607:f8b0:4864:20::736]) (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 4F30E3A0CB9 for ; Thu, 9 Sep 2021 11:49:44 -0700 (PDT) Received: by mail-qk1-x736.google.com with SMTP id 22so2942854qkg.2 for ; Thu, 09 Sep 2021 11:49:44 -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=qJbdoAr3rwPB4bhtTvFglrsbI+V1kk1Y13yVG2ZWm80=; b=lrdEzdqsyLSCuFtGcGCXJ432/ZwtOBfWqzphY5svitkHhBAkb66pf3C28LZ7a5cO5E Uh36bAed6t+0ne6YM6bUMEhibB/34WQ7AaMaDtwMFX9wYXW/lDr49Qedgnad6p9z2uQf MJqEAsekpLyylsCfrcbUsiE+K7lJdeUOOJtOjmYic8c0hXyj5aix5iVB1cccuJntzI83 1ageMDZvWjj+cS4rTGuUfZnX5KmWBwraVuB4FZYLbBtb7RLC5FCJBYBabsgKk+jL7/zI fnJA8eWCTyWYzx6M9wW3OJ5lZef0d9TkKEQ4qxriRzWqi4Yk8a5CQRgbNfpVnxfUpZ7E f5kA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=qJbdoAr3rwPB4bhtTvFglrsbI+V1kk1Y13yVG2ZWm80=; b=X7GS5YG32ciky8sdsnnCsejLxN18T1/k1sq03Vnd52HFWcBjOb1i0hgAUZtF5HU+px zzb6/A+xynQblwdkMyrtVWRV6LqGJFH5+vqGc/6W9M/jK04O4igElFeNWfu4TBblkVsZ WyzQ4R0HloewB/S7S4rG0N3Aa7+xW/f9lnRvz+nFx3+OPuIjPMIRZk5zk0wW7BtiUmsv eZ4sNSvs+fC3IKPNvpyx1w4wy/6+6OSviTrMhmfb2JJmVjwB9g8u95LAk1IACmBU4FVq /u24A3HhY8Nx7ACqWIxmiJ8PX4USwpLgJ8w75YARy5ZbiEQw/HFokPPTJ1tve6U/Y0Qo hjcA== X-Gm-Message-State: AOAM531KyRK2m8ncIzqRoIrMRZiP/SQLoVu6LJSuzvChPsdaK5GAFOBj 8rHggqQznBriH65sqKkUkq1VJspEFXr07EQuc9XbiDrxVKQ= X-Google-Smtp-Source: ABdhPJwSg0ka3F/wvDPdkWcK5S7SVgWqQy5sc0os1C9imf2QfJakDo/hP9kRyM9CLjR5suvCt8ylbBTTyZvZKmu2GGk= X-Received: by 2002:ae9:e204:: with SMTP id c4mr4122961qkc.125.1631213382365; Thu, 09 Sep 2021 11:49:42 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Richard Barnes Date: Thu, 9 Sep 2021 14:49:31 -0400 Message-ID: To: Bernard Aboba Cc: Sergio Garcia Murillo , sframe@ietf.org Content-Type: multipart/alternative; boundary="00000000000035890605cb9476df" Archived-At: Subject: Re: [Sframe] Negotiating SFrame/RTP in SDP X-BeenThere: sframe@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Secure Media Frames List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Sep 2021 18:49:50 -0000 --00000000000035890605cb9476df Content-Type: text/plain; charset="UTF-8" Hi Bernard, On the question of why we're doing SDP here at all, the main reason that comes to my mind is: Giving SFUs fair notice of what's going on so that they can act intelligently on E2E-encrypted streams. There might be some secondary benefits to setting up endpoints. It is worth noting that the current round of implementations (both IS-based ones and Webex) demonstrate that E2EE calls can be done without any changes to SDP, as long as SFUs don't get upset when they can't interpret the media. The potential benefits of having some standardization of signaling would be (1) to let SFUs react more intelligently in these situations, say by requesting different RTP extensions, and (2) simplifying some of the endpoint configuration that is needed to make SFrame work (or at least letting an endpoint fail faster, say if it doesn't have any keys for SFrame). With regard to downgrade: First, in some applications, there is a signaling level above SDP (like SIP, or some HTTP thing for WebRTC), that is independent of the SFU and could thus distribute an E2EE signal to allow detection of downgrade. Second, if all the infrastructure is adversarial, then it's up to the clients to signal somehow whether a given call is E2EE. --RLB On Mon, Sep 6, 2021 at 7:39 PM Bernard Aboba wrote: > Richard said: > > "Just add an SFrame protect/unprotect before you do other processing on > the media payload. Then you will have a payload that is as described in > the SDP." > > [BA] If the SFU is untrusted to have cleartext access to the payload, why > would the endpoint use SDP to negotiate with the SFU whether to use E2E > encryption? This potentially enables a downgrade attack. > > Such a negotiation only makes sense in a use case where there are some > clients that support E2E encryption and others that do not, and the SFU is > looking to gracefully keep the non-E2E endpoints out of the conference > (e.g. by failing the O/A negotiation, instead of succeeding and then having > the non-E2E endpoints being unable to parse the codec payloads). > > Sergio said: > > "Also, not always the media server and the endpoints are provided by the > same company (i.e. CPaaS) and they will have to support both end to end > encryption and non end to end encryption calls. " > > [BA] SDP negotiation between the endpoint and SFU is useful in > negotiating hop-by-hop parameters, such as the RTP header extensions needed > by the SFU to forward packets without inspecting the RTP payload. > > But in a CPaaS scenario, I agree that the application will determine > whether to use E2E encryption or not and the SFU need not know or care, > since it isn't parsing the codec payloads anyway. In that scenario you > won't have a mixture of E2E capable and non-capable endpoints, so the SDP > negotiation would serve no useful purpose. > > > > On Mon, Sep 6, 2021 at 12:14 PM Sergio Garcia Murillo < > sergio.garcia.murillo@cosmosoftware.io> wrote: > >> From my point of view, all the mechanisms described on the multi codec >> payload format are required: >> >> The ability to differentiate a RTP packet encrypted end to end (either by >> SFrame or SPacket) is a must, both from a formal point of view about how >> RTP works, but also to ensure that the media servers does not perform any >> payload inspection that will cause malfunction (metadata gathering, layer >> switching, recording..) >> >> The optionality of the encryption also comes from various factors. First, >> end to end encryption is an "endpoint" decision, the SDP negotiation with >> the media server should not be the place to enforce it or not. Also, not >> always the media server and the endpoints are provided by the same company >> (i.e. CPaaS) and they will have to support both end to end encryption and >> non end to end encryption calls. Note that it is quite a common practice in >> SFUs to send an SDP offer from the media server to the endpoint, in which >> case, the media server will have to offer e2e encryption as optional. >> >> As an example, in Millicast we support both e2ee and non-e2ee streams >> today (with the insertable stream per codec hacks), it is a >> completely optional feature up to each customer to implement and to decide >> when and if it is used. We are just carriers, and we do not want the >> customer to have to configure if the stream is e2ee or not. We are not (and >> must not be) involved in enforcing e2ee in any way. >> >> Best regards >> Sergio >> >> On Thu, Sep 2, 2021 at 10:23 PM Richard Barnes wrote: >> >>> Hi folks, >>> >>> One of the major work items left around SFrame is the work to specify >>> how SFrame-encrypted media are carried in RTP, and how that is signaled in >>> SDP. The finer points might need to be worked out in AVTCORE / MMUSIC, but >>> since this group knows the intricacies better, it seems like having some >>> agreement here on general approach would be good. >>> >>> Sergio put together a first stab at this in >>> draft-murillo-avtcore-multi-codec-payload-format [1]. He presented this at >>> AVTCORE @ IETF 111 [2]. Unfortunately, the discussion there doesn't seem >>> to have provided a clear path forward, thus this thread. >>> >>> Personally, I think the proposal in Sergio's draft is a little wide of >>> the mark. ISTM that specifying a "generic" media format and recovering the >>> specificity in an RTP header is more complex than is needed. Worse, it sets >>> up implementations to send the same media both encrypted and unencrypted -- >>> obviously not great for security. >>> >>> I'd like to propose a simpler approach, drawing inspiration from cryptex >>> [3]: >>> >>> a=sframe: [] >>> >>> Basically, just a new SDP attribute per m-line, that specifies that >>> SFrame encryption is being done and how. The desired semantic is clear for >>> SPacket: Just add an SFrame protect/unprotect before you do other >>> processing on the media payload. Then you will have a payload that is as >>> described in the SDP. >>> >>> You can *almost* describe SFrame in this way as well. Assemble all the >>> RTP packets in a frame, then do SFrame across all of their payloads (in >>> particular, adding the header to the first packet and the tag to the >>> last). If you constrained the sender to construct pre-SFrame packets that >>> were properly packetized according to the rest of the SDP, then this would >>> integrate cleanly with the rest of the SDP/RTP model. The problem is that >>> that constraint is incompatible with Insertable Streams. So we need to >>> decide how much we care about compatibility with IS as it is. Personally, >>> it seems like WebRTC stacks and web apps are going to have to upgrade >>> *anyway* if they're going to support SDP-based negotiation of SFrame, so if >>> they have to make this one extra change, it shouldn't be a big deal. >>> >>> How does this approach strike folks? >>> >>> --Richard >>> >>> [1] >>> https://www.ietf.org/archive/id/draft-murillo-avtcore-multi-codec-payload-format-01.html >>> [2] https://youtu.be/S-JR4Fa8VFY?t=3510 >>> [3] >>> https://www.ietf.org/archive/id/draft-ietf-avtcore-cryptex-02.html#name-signaling >>> -- >>> Sframe mailing list >>> Sframe@ietf.org >>> https://www.ietf.org/mailman/listinfo/sframe >>> >> -- >> Sframe mailing list >> Sframe@ietf.org >> https://www.ietf.org/mailman/listinfo/sframe >> > --00000000000035890605cb9476df Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Bernard,

On the question = of why we're doing SDP here at all, the main reason that comes to my mi= nd is: Giving SFUs fair notice of what's going on so that they can act = intelligently on E2E-encrypted streams.=C2=A0 There might be some secondary= benefits to setting up endpoints.

It is worth= noting that the current round of implementations (both IS-based ones and W= ebex) demonstrate that E2EE calls can be done without any changes to SDP, a= s long as SFUs don't get upset when they can't interpret the media.= =C2=A0 The potential benefits of having some standardization of signaling w= ould be (1) to let SFUs react more intelligently in these situations, say b= y requesting different RTP extensions, and (2) simplifying some of the endp= oint configuration that is needed to make SFrame work (or at least letting = an endpoint fail faster, say if it doesn't have any keys for SFrame).

With regard to downgrade: First, in some applic= ations, there is a signaling level above SDP (like SIP, or some HTTP thing = for WebRTC), that is independent of the SFU and could thus distribute an E2= EE signal to allow detection of downgrade.=C2=A0 Second, if all the infrast= ructure is adversarial, then it's up to the clients to signal somehow w= hether a given call is E2EE.

--RLB
<= br>



On Mon, Sep 6, 2021 at 7:39 PM Berna= rd Aboba <bernard.aboba@gmail= .com> wrote:
Richard said:=C2=A0

"Just add = an SFrame protect/unprotect before you do other processing on the media pay= load.=C2=A0 Then you will have a payload that is as described in the SDP.&q= uot;

[BA]=C2=A0 If the SFU is untrusted to have cl= eartext access to the payload, why would the endpoint use SDP to negotiate = with the SFU whether to use E2E encryption?=C2=A0 This potentially enables = a downgrade attack.=C2=A0=C2=A0

Such a negotiation= only makes sense in a use case where there are=C2=A0some clients that supp= ort E2E encryption and others that do not, and the SFU is looking to gracef= ully keep the non-E2E endpoints out of the conference (e.g. by failing the = O/A negotiation, instead of succeeding and then having the non-E2E endpoint= s being unable=C2=A0to parse the codec payloads).=C2=A0

Sergio said:=C2=A0

"Also, not always the medi= a server and the endpoints are provided by the same company (i.e. CPaaS) an= d they will have to support both end to end encryption and non end to end e= ncryption calls. "

[BA]=C2=A0 SDP negotiation= between the endpoint and SFU is useful in negotiating hop-by-hop parameter= s, such as the RTP header extensions needed by the SFU to forward packets w= ithout inspecting the RTP payload.=C2=A0=C2=A0

But= in a CPaaS scenario, I agree that the application will determine whether t= o use E2E encryption or not and the SFU need not know or care, since it isn= 't parsing the codec payloads anyway.=C2=A0 In that scenario you won= 9;t have a mixture of E2E capable and non-capable endpoints, so the SDP neg= otiation would serve no useful purpose.


=

On Mon, Sep 6, 2021 at 12:14 PM Sergio Garcia Murillo <sergio.gar= cia.murillo@cosmosoftware.io> wrote:
From my point of view, al= l the mechanisms described on the multi codec payload format are required:<= /div>

The ability to differentiate a RTP packet encrypte= d end to end (either by SFrame or SPacket) is a must, both from a formal po= int of view about how RTP works, but also to ensure that the media servers = does not perform any payload inspection that will cause malfunction (metada= ta gathering, layer switching, recording..)=C2=A0

= The optionality of the encryption also comes from various factors. First, e= nd to end encryption is an "endpoint" decision, the SDP negotiati= on with the media server should not be the place to enforce it or not. Also= , not always the media server and the endpoints are provided by the same co= mpany (i.e. CPaaS) and they will have to support both end to end encryption= and non end to end encryption calls. Note that it is quite a common practi= ce in SFUs to send an SDP offer from the media server to the endpoint, in w= hich case, the media server will have to offer e2e encryption as optional.<= /div>

As an example, in Millicast we support both e2ee a= nd non-e2ee streams today (with the insertable stream per codec hacks), it = is a completely=C2=A0optional feature up to each customer to implement and = to decide when and if it is used. We are just carriers, and we do not=C2=A0= want the customer to have to configure if the stream is e2ee or not. We are= not (and must not be) involved in enforcing e2ee in any way.=C2=A0

Best regards
Sergio

On Thu, Sep 2, 2021 at 10:23= PM Richard Barnes <rlb@= ipv.sx> wrote:
Hi folks,

One of the major work items left ar= ound SFrame is the work to specify how SFrame-encrypted media are carried i= n RTP, and how that is signaled in SDP.=C2=A0 The finer points might need t= o be worked out in AVTCORE / MMUSIC, but since this group knows the intrica= cies better, it seems like having some agreement here on general approach w= ould be good.

Sergio put together a first stab at this in draft-muri= llo-avtcore-multi-codec-payload-format [1].=C2=A0 He presented this at AVTC= ORE @ IETF 111 [2].=C2=A0 Unfortunately, the discussion there doesn't s= eem to have provided a clear path forward, thus this thread.

Persona= lly, I think the proposal in Sergio's draft is a little wide of the mar= k.=C2=A0 ISTM that specifying a "generic" media format and recove= ring the specificity in an RTP header is more complex than is needed. Worse= , it sets up implementations to send the same media both encrypted and unen= crypted -- obviously not great for security.

I'd like to propose= a simpler approach, drawing inspiration from cryptex [3]:

a=3Dsfram= e:<frame|packet> [<keying>]

Basically, just a new SDP at= tribute per m-line, that specifies that SFrame encryption is being done and= how.=C2=A0 The desired semantic is clear for SPacket: Just add an SFrame p= rotect/unprotect before you do other processing on the media payload.=C2=A0= Then you will have a payload that is as described in the SDP.

You c= an *almost* describe SFrame in this way as well.=C2=A0 Assemble all the RTP= packets in a frame, then do SFrame across all of their payloads (in partic= ular, adding the header to the first packet and the tag to the last).=C2=A0= If you constrained the sender to construct pre-SFrame packets =C2=A0that w= ere properly packetized according to the rest of the SDP, then this would i= ntegrate cleanly with the rest of the SDP/RTP model.=C2=A0 The problem is t= hat that constraint is incompatible with Insertable Streams.=C2=A0 So we ne= ed to decide how much we care about compatibility with IS as it is.=C2=A0 P= ersonally, it seems like WebRTC stacks and web apps are going to have to up= grade *anyway* if they're going to support SDP-based negotiation of SFr= ame, so if they have to make this one extra change, it shouldn't be a b= ig deal.

How does this approach strike folks?

--Richard
[1] https://www.ietf.org/arch= ive/id/draft-murillo-avtcore-multi-codec-payload-format-01.html
[2] = https:/= /youtu.be/S-JR4Fa8VFY?t=3D3510
[3] https://www.ietf.org/archive/id/draft-ietf-avtcore-cryptex-02.html#name= -signaling
--
Sframe mailing list
Sframe@ietf.org https://www.ietf.org/mailman/listinfo/sframe
--
Sframe mailing list
Sframe@ietf.org https://www.ietf.org/mailman/listinfo/sframe
--00000000000035890605cb9476df-- From nobody Thu Sep 9 13:51:56 2021 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 111883A00B0 for ; Thu, 9 Sep 2021 13:51:54 -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 S6YUpmuPb7ut for ; Thu, 9 Sep 2021 13:51:49 -0700 (PDT) Received: from mail-lf1-x134.google.com (mail-lf1-x134.google.com [IPv6:2a00:1450:4864:20::134]) (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 704F43A0068 for ; Thu, 9 Sep 2021 13:51:48 -0700 (PDT) Received: by mail-lf1-x134.google.com with SMTP id t19so6194893lfe.13 for ; Thu, 09 Sep 2021 13:51:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=AH6e3zpwLUef44i6n0JVuOlwh8PWJFqlM3J7mgIlZjg=; b=FnBQPF1KPIXkvWxEI4iCcdmrQi/ODwRD0uhsaTfv+xEIcK13tN3fjwX2R8Lg9py+Wb 339SIT9SrEKxchFu7Kr/V+otK8y24/I/YTwun72T/WqmD43Jx8wmvpXnDQoUslJJVosv HlXtAn+Z8DtyCA7uYr0pK2Ih5LAuEtrSayStaQS6I5wn9+WEsfjAyYSHtHdbQuCQT26R qIFHAXNJaEMy/QLU/zQrZjv1Lc2IBdQnIr+CVZWtnaMW895w/6pdbGdXz3tlmINiLiH0 K1ddrmXytx5t1Wk6+yEP+R+8SwZb+M2x+TBUYwBIuM351l9UaMa30ShV/H27LPOhe0BK BWtQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=AH6e3zpwLUef44i6n0JVuOlwh8PWJFqlM3J7mgIlZjg=; b=2N+jEXo3guxlZFmKIKhV9ekbP5z7OWlfwdTam5AXRosXUhHtw8nZ66aa3vREV0oAN6 OIQOTArXatzfUrc1pz/J7y/KKDMsdHoxfMansQBCHTdgliDEzHNXBczySg2n/v1EDkzt yRtSBf0zO/qoMVH6Ko+XABHZE/p0OIeNnR3dBA4ji35j3DlT3pHVwrl5tqWTmLScbfeB eKvwif/9HwqSU3rk1G41IpwG/Nmq3ISgCJ8NNXJGTFjegvGd/2ylNQIVUc/KwAeojm4S Y4dWMY4tosOeOSE8Gg798orgYYGUjpFw0zXPB7iPewJbEyrNu+LXirzRLnm5LgiLvKnO wj4g== X-Gm-Message-State: AOAM533ubK+i/Zz+GzC0RgP28sgv9T5sX0s4qIPWiv3aSvK3vWTVirSd Oz/we2ZJL42UWiVabBi5X44eP2X1QhfKUHksFTOSM2RzkEQ= X-Google-Smtp-Source: ABdhPJwcd5iNZHBsOJXq24q4WC9Zl93AS0day+brXlaUdP9Ow2uP6XsR9TfOPpg/L7LqVQi43ctDapRkJjczV2KVRvs= X-Received: by 2002:a05:6512:22c2:: with SMTP id g2mr1265977lfu.11.1631220705257; Thu, 09 Sep 2021 13:51:45 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Bernard Aboba Date: Thu, 9 Sep 2021 13:51:35 -0700 Message-ID: To: Richard Barnes Cc: Sergio Garcia Murillo , sframe@ietf.org Content-Type: multipart/alternative; boundary="000000000000afefd705cb962af9" Archived-At: Subject: Re: [Sframe] Negotiating SFrame/RTP in SDP X-BeenThere: sframe@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Secure Media Frames List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Sep 2021 20:51:54 -0000 --000000000000afefd705cb962af9 Content-Type: text/plain; charset="UTF-8" "On the question of why we're doing SDP here at all, the main reason that comes to my mind is: Giving SFUs fair notice of what's going on so that they can act intelligently on E2E-encrypted streams. There might be some secondary benefits to setting up endpoints. It is worth noting that the current round of implementations (both IS-based ones and Webex) demonstrate that E2EE calls can be done without any changes to SDP, as long as SFUs don't get upset when they can't interpret the media. " [BA] By negotiating RTP header extensions designed to enable payload-agnostic forwarding (e.g. framemarking, DD, etc.), the SFU can obtain the information it needs to forward packets without having to parse the payload. The question is whether this is sufficient. It seems to me that SDP can enable a compatible combination of RTP header extension and codecs to be determined, but there can be complications. For example, the endpoint might support framemarking with the H.264 codec but not with VP8 or VP9, which are also supported. Unfortunately, the SFU only supports forwarding VP8, VP9 and AV1 as well as the Dependency Descriptor RTP header extension but not framemarking. In this situation, O/A negotiation will result in the endpoint and SFU negotiating VP8 or VP9 without a forwarding RTP header extension. If the endpoint then attempts to encrypt E2E, the SFU will "get upset", because it will attempt to parse the payload, having no other means available to forward the packets. If E2E encryption is an endpoint requirement, the endpoint can refuse to proceed with the call. That would probably be the appropriate outcome since it knows that the SFU doesn't support the combination of codecs and RTP header extensions necessary to make E2E encryption work. Richard also said: "The potential benefits of having some standardization of signaling would be (1) to let SFUs react more intelligently in these situations, say by requesting different RTP extensions, and (2) simplifying some of the endpoint configuration that is needed to make SFrame work (or at least letting an endpoint fail faster, say if it doesn't have any keys for SFrame)." [BA] SDP allows the SFU to tell the endpoint what codecs and RTP header extensions it supports, and for the endpoint to do the same. So the basic info can be exchanged in a single found of Offer/Answer. Is it possible to implement "Intelligence" at a higher layer, within the application? That would simplify things. Richard also said: With regard to downgrade: First, in some applications, there is a signaling level above SDP (like SIP, or some HTTP thing for WebRTC), that is independent of the SFU and could thus distribute an E2EE signal to allow detection of downgrade. Second, if all the infrastructure is adversarial, then it's up to the clients to signal somehow whether a given call is E2EE. [BA] Could the client "signal" be provided in the media? Remember that SFRAME isn't tied to RTP necessarily (e.g. SFRAMEs can be transmitted over WebRTC data channel, WebTransport, etc.). So you have a lot of freedom here. On Thu, Sep 9, 2021 at 11:49 AM Richard Barnes wrote: > Hi Bernard, > > On the question of why we're doing SDP here at all, the main reason that > comes to my mind is: Giving SFUs fair notice of what's going on so that > they can act intelligently on E2E-encrypted streams. There might be some > secondary benefits to setting up endpoints. > > It is worth noting that the current round of implementations (both > IS-based ones and Webex) demonstrate that E2EE calls can be done without > any changes to SDP, as long as SFUs don't get upset when they can't > interpret the media. The potential benefits of having some standardization > of signaling would be (1) to let SFUs react more intelligently in these > situations, say by requesting different RTP extensions, and (2) simplifying > some of the endpoint configuration that is needed to make SFrame work (or > at least letting an endpoint fail faster, say if it doesn't have any keys > for SFrame). > > With regard to downgrade: First, in some applications, there is a > signaling level above SDP (like SIP, or some HTTP thing for WebRTC), that > is independent of the SFU and could thus distribute an E2EE signal to allow > detection of downgrade. Second, if all the infrastructure is adversarial, > then it's up to the clients to signal somehow whether a given call is E2EE. > > --RLB > > > > > On Mon, Sep 6, 2021 at 7:39 PM Bernard Aboba > wrote: > >> Richard said: >> >> "Just add an SFrame protect/unprotect before you do other processing on >> the media payload. Then you will have a payload that is as described in >> the SDP." >> >> [BA] If the SFU is untrusted to have cleartext access to the payload, >> why would the endpoint use SDP to negotiate with the SFU whether to use E2E >> encryption? This potentially enables a downgrade attack. >> >> Such a negotiation only makes sense in a use case where there are some >> clients that support E2E encryption and others that do not, and the SFU is >> looking to gracefully keep the non-E2E endpoints out of the conference >> (e.g. by failing the O/A negotiation, instead of succeeding and then having >> the non-E2E endpoints being unable to parse the codec payloads). >> >> Sergio said: >> >> "Also, not always the media server and the endpoints are provided by the >> same company (i.e. CPaaS) and they will have to support both end to end >> encryption and non end to end encryption calls. " >> >> [BA] SDP negotiation between the endpoint and SFU is useful in >> negotiating hop-by-hop parameters, such as the RTP header extensions needed >> by the SFU to forward packets without inspecting the RTP payload. >> >> But in a CPaaS scenario, I agree that the application will determine >> whether to use E2E encryption or not and the SFU need not know or care, >> since it isn't parsing the codec payloads anyway. In that scenario you >> won't have a mixture of E2E capable and non-capable endpoints, so the SDP >> negotiation would serve no useful purpose. >> >> >> >> On Mon, Sep 6, 2021 at 12:14 PM Sergio Garcia Murillo < >> sergio.garcia.murillo@cosmosoftware.io> wrote: >> >>> From my point of view, all the mechanisms described on the multi codec >>> payload format are required: >>> >>> The ability to differentiate a RTP packet encrypted end to end (either >>> by SFrame or SPacket) is a must, both from a formal point of view about how >>> RTP works, but also to ensure that the media servers does not perform any >>> payload inspection that will cause malfunction (metadata gathering, layer >>> switching, recording..) >>> >>> The optionality of the encryption also comes from various factors. >>> First, end to end encryption is an "endpoint" decision, the SDP negotiation >>> with the media server should not be the place to enforce it or not. Also, >>> not always the media server and the endpoints are provided by the same >>> company (i.e. CPaaS) and they will have to support both end to end >>> encryption and non end to end encryption calls. Note that it is quite a >>> common practice in SFUs to send an SDP offer from the media server to the >>> endpoint, in which case, the media server will have to offer e2e encryption >>> as optional. >>> >>> As an example, in Millicast we support both e2ee and non-e2ee streams >>> today (with the insertable stream per codec hacks), it is a >>> completely optional feature up to each customer to implement and to decide >>> when and if it is used. We are just carriers, and we do not want the >>> customer to have to configure if the stream is e2ee or not. We are not (and >>> must not be) involved in enforcing e2ee in any way. >>> >>> Best regards >>> Sergio >>> >>> On Thu, Sep 2, 2021 at 10:23 PM Richard Barnes wrote: >>> >>>> Hi folks, >>>> >>>> One of the major work items left around SFrame is the work to specify >>>> how SFrame-encrypted media are carried in RTP, and how that is signaled in >>>> SDP. The finer points might need to be worked out in AVTCORE / MMUSIC, but >>>> since this group knows the intricacies better, it seems like having some >>>> agreement here on general approach would be good. >>>> >>>> Sergio put together a first stab at this in >>>> draft-murillo-avtcore-multi-codec-payload-format [1]. He presented this at >>>> AVTCORE @ IETF 111 [2]. Unfortunately, the discussion there doesn't seem >>>> to have provided a clear path forward, thus this thread. >>>> >>>> Personally, I think the proposal in Sergio's draft is a little wide of >>>> the mark. ISTM that specifying a "generic" media format and recovering the >>>> specificity in an RTP header is more complex than is needed. Worse, it sets >>>> up implementations to send the same media both encrypted and unencrypted -- >>>> obviously not great for security. >>>> >>>> I'd like to propose a simpler approach, drawing inspiration from >>>> cryptex [3]: >>>> >>>> a=sframe: [] >>>> >>>> Basically, just a new SDP attribute per m-line, that specifies that >>>> SFrame encryption is being done and how. The desired semantic is clear for >>>> SPacket: Just add an SFrame protect/unprotect before you do other >>>> processing on the media payload. Then you will have a payload that is as >>>> described in the SDP. >>>> >>>> You can *almost* describe SFrame in this way as well. Assemble all the >>>> RTP packets in a frame, then do SFrame across all of their payloads (in >>>> particular, adding the header to the first packet and the tag to the >>>> last). If you constrained the sender to construct pre-SFrame packets that >>>> were properly packetized according to the rest of the SDP, then this would >>>> integrate cleanly with the rest of the SDP/RTP model. The problem is that >>>> that constraint is incompatible with Insertable Streams. So we need to >>>> decide how much we care about compatibility with IS as it is. Personally, >>>> it seems like WebRTC stacks and web apps are going to have to upgrade >>>> *anyway* if they're going to support SDP-based negotiation of SFrame, so if >>>> they have to make this one extra change, it shouldn't be a big deal. >>>> >>>> How does this approach strike folks? >>>> >>>> --Richard >>>> >>>> [1] >>>> https://www.ietf.org/archive/id/draft-murillo-avtcore-multi-codec-payload-format-01.html >>>> [2] https://youtu.be/S-JR4Fa8VFY?t=3510 >>>> [3] >>>> https://www.ietf.org/archive/id/draft-ietf-avtcore-cryptex-02.html#name-signaling >>>> -- >>>> Sframe mailing list >>>> Sframe@ietf.org >>>> https://www.ietf.org/mailman/listinfo/sframe >>>> >>> -- >>> Sframe mailing list >>> Sframe@ietf.org >>> https://www.ietf.org/mailman/listinfo/sframe >>> >> --000000000000afefd705cb962af9 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
"On the question of why we're doing SDP here= at all, the main reason that comes to my mind is: Giving SFUs fair notice = of what's going on so that they can act intelligently on E2E-encrypted = streams.=C2=A0 There might be some secondary benefits to setting up endpoin= ts.

It is worth noting that the current round of i= mplementations (both IS-based ones and Webex) demonstrate that E2EE calls c= an be done without any changes to SDP, as long as SFUs don't get upset = when they can't interpret the media. "

[BA] By negotiating RTP header extensions designed to enable payload-agno= stic forwarding (e.g. framemarking, DD, etc.), the SFU can obtain the infor= mation it needs to forward packets without having to parse the payload.=C2= =A0

The question is whether this is sufficient.=C2= =A0

It seems to me that SDP can enable a compatibl= e combination of RTP header extension and codecs to be determined, but ther= e can be complications.

For example, the endpoint = might support framemarking with the H.264 codec but not with VP8 or VP9, wh= ich are also supported. Unfortunately, the SFU only supports forwarding VP8= , VP9 and AV1 as well as the Dependency Descriptor RTP header extension but= not framemarking.=C2=A0

In this situation, O/A ne= gotiation will result in the endpoint and SFU negotiating VP8 or VP9 withou= t a forwarding RTP header extension. If the endpoint then attempts to encry= pt E2E, the SFU will "get upset", because it will attempt to pars= e the payload, having no other means available to forward the packets.

If E2E encryption is an endpoint requirement, the endp= oint can refuse to proceed with the call.=C2=A0 That would probably be the = appropriate outcome since it knows that the SFU doesn't support the com= bination of codecs and RTP header extensions necessary to make E2E encrypti= on work.=C2=A0

Richard also said:=C2=A0
=
"The potential benefits of having some standardization = of signaling would be (1) to let SFUs react more intelligently in these sit= uations, say by requesting different RTP extensions, and (2) simplifying so= me of the endpoint configuration that is needed to make SFrame work (or at = least letting an endpoint fail faster, say if it doesn't have any keys = for SFrame)."

[BA] SDP allows the SFU to = tell the endpoint what codecs and RTP header extensions it supports, and fo= r the endpoint to do the same. So the basic info can be exchanged in a sing= le found of Offer/Answer.=C2=A0 Is it possible to implement "Intellige= nce" at a higher layer, within the application?=C2=A0 That would simpl= ify things.=C2=A0

Richard also said:=C2=A0

With regard to downgrade: First, in some applications, th= ere is a signaling level above SDP (like SIP, or some HTTP thing for WebRTC= ), that is independent of the SFU and could thus distribute an E2EE signal = to allow detection of downgrade.=C2=A0 Second, if all the infrastructure is= adversarial, then it's up to the clients to signal somehow whether a g= iven call is E2EE.

[BA] Could the client "sig= nal" be provided in the media?=C2=A0 Remember that SFRAME isn't ti= ed to RTP necessarily (e.g. SFRAMEs can be transmitted over WebRTC data cha= nnel, WebTransport, etc.).=C2=A0 So you have a lot of freedom here.

On= Thu, Sep 9, 2021 at 11:49 AM Richard Barnes <rlb@ipv.sx> wrote:
Hi Bernard,

On= the question of why we're doing SDP here at all, the main reason that = comes to my mind is: Giving SFUs fair notice of what's going on so that= they can act intelligently on E2E-encrypted streams.=C2=A0 There might be = some secondary benefits to setting up endpoints.

It is worth noting that the current round of implementations (both IS-ba= sed ones and Webex) demonstrate that E2EE calls can be done without any cha= nges to SDP, as long as SFUs don't get upset when they can't interp= ret the media.=C2=A0 The potential benefits of having some standardization = of signaling would be (1) to let SFUs react more intelligently in these sit= uations, say by requesting different RTP extensions, and (2) simplifying so= me of the endpoint configuration that is needed to make SFrame work (or at = least letting an endpoint fail faster, say if it doesn't have any keys = for SFrame).

With regard to downgrade: First, = in some applications, there is a signaling level above SDP (like SIP, or so= me HTTP thing for WebRTC), that is independent of the SFU and could thus di= stribute an E2EE signal to allow detection of downgrade.=C2=A0 Second, if a= ll the infrastructure is adversarial, then it's up to the clients to si= gnal somehow whether a given call is E2EE.

--RLB




On Mon, Sep 6, 2021 = at 7:39 PM Bernard Aboba <bernard.aboba@gmail.com> wrote:
Richard said:=C2=A0<= div>
"Just add an SFrame protect/unprotect before you do= other processing on the media payload.=C2=A0 Then you will have a payload = that is as described in the SDP."

[BA]=C2=A0 = If the SFU is untrusted to have cleartext access to the payload, why would = the endpoint use SDP to negotiate with the SFU whether to use E2E encryptio= n?=C2=A0 This potentially enables a downgrade attack.=C2=A0=C2=A0

Such a negotiation only makes sense in a use case where the= re are=C2=A0some clients that support E2E encryption and others that do not= , and the SFU is looking to gracefully keep the non-E2E endpoints out of th= e conference (e.g. by failing the O/A negotiation, instead of succeeding an= d then having the non-E2E endpoints being unable=C2=A0to parse the codec pa= yloads).=C2=A0

Sergio said:=C2=A0

"Also, not always the media server and the endpoints are provided b= y the same company (i.e. CPaaS) and they will have to support both end to e= nd encryption and non end to end encryption calls. "

[BA]=C2=A0 SDP negotiation between the endpoint and SFU is useful i= n negotiating hop-by-hop parameters, such as the RTP header extensions need= ed by the SFU to forward packets without inspecting the RTP payload.=C2=A0= =C2=A0

But in a CPaaS scenario, I agree that the a= pplication will determine whether to use E2E encryption or not and the SFU = need not know or care, since it isn't parsing the codec payloads anyway= .=C2=A0 In that scenario you won't have a mixture of E2E capable and no= n-capable endpoints, so the SDP negotiation would serve no useful purpose.<= /div>



On Mon, Sep 6, 2021 at 12:14 PM Se= rgio Garcia Murillo <sergio.garcia.murillo@cosmosoftware.io> wro= te:
From my point of view, all the mechanisms described on the multi = codec payload format are required:

The ability to = differentiate a RTP packet encrypted end to end (either by SFrame or SPacke= t) is a must, both from a formal point of view about how RTP works, but als= o to ensure that the media servers does not perform any payload inspection = that will cause malfunction (metadata gathering, layer switching, recording= ..)=C2=A0

The optionality of the encryption also c= omes from various factors. First, end to end encryption is an "endpoin= t" decision, the SDP negotiation with the media server should not be t= he place to enforce it or not. Also, not always the media server and the en= dpoints are provided by the same company (i.e. CPaaS) and they will have to= support both end to end encryption and non end to end encryption calls. No= te that it is quite a common practice in SFUs to send an SDP offer from the= media server to the endpoint, in which case, the media server will have to= offer e2e encryption as optional.

As an example, = in Millicast we support both e2ee and non-e2ee streams today (with the inse= rtable stream per codec hacks), it is a completely=C2=A0optional feature up= to each customer to implement and to decide when and if it is used. We are= just carriers, and we do not=C2=A0want the customer to have to configure i= f the stream is e2ee or not. We are not (and must not be) involved in enfor= cing e2ee in any way.=C2=A0

Best regards
Sergio

On Thu, Sep 2, 2021 at 10:23 PM Richard Barnes <rlb@ipv.sx> wrote:
Hi folks,

= One of the major work items left around SFrame is the work to specify how S= Frame-encrypted media are carried in RTP, and how that is signaled in SDP.= =C2=A0 The finer points might need to be worked out in AVTCORE / MMUSIC, bu= t since this group knows the intricacies better, it seems like having some = agreement here on general approach would be good.

Sergio put togethe= r a first stab at this in draft-murillo-avtcore-multi-codec-payload-format = [1].=C2=A0 He presented this at AVTCORE @ IETF 111 [2].=C2=A0 Unfortunately= , the discussion there doesn't seem to have provided a clear path forwa= rd, thus this thread.

Personally, I think the proposal in Sergio'= ;s draft is a little wide of the mark.=C2=A0 ISTM that specifying a "g= eneric" media format and recovering the specificity in an RTP header i= s more complex than is needed. Worse, it sets up implementations to send th= e same media both encrypted and unencrypted -- obviously not great for secu= rity.

I'd like to propose a simpler approach, drawing inspiratio= n from cryptex [3]:

a=3Dsframe:<frame|packet> [<keying>]=

Basically, just a new SDP attribute per m-line, that specifies that= SFrame encryption is being done and how.=C2=A0 The desired semantic is cle= ar for SPacket: Just add an SFrame protect/unprotect before you do other pr= ocessing on the media payload.=C2=A0 Then you will have a payload that is a= s described in the SDP.

You can *almost* describe SFrame in this way= as well.=C2=A0 Assemble all the RTP packets in a frame, then do SFrame acr= oss all of their payloads (in particular, adding the header to the first pa= cket and the tag to the last).=C2=A0 If you constrained the sender to const= ruct pre-SFrame packets =C2=A0that were properly packetized according to th= e rest of the SDP, then this would integrate cleanly with the rest of the S= DP/RTP model.=C2=A0 The problem is that that constraint is incompatible wit= h Insertable Streams.=C2=A0 So we need to decide how much we care about com= patibility with IS as it is.=C2=A0 Personally, it seems like WebRTC stacks = and web apps are going to have to upgrade *anyway* if they're going to = support SDP-based negotiation of SFrame, so if they have to make this one e= xtra change, it shouldn't be a big deal.

How does this approach = strike folks?

--Richard

[1] https://www.ietf.org/archive/id/draft-murillo-avtcore-multi-cod= ec-payload-format-01.html
[2] https://youtu.be/S-JR4Fa8VFY?t=3D3510
= [3] https://www.ietf.org/archive/id/dr= aft-ietf-avtcore-cryptex-02.html#name-signaling
--
Sframe mailing list
Sframe@ietf.org https://www.ietf.org/mailman/listinfo/sframe
--
Sframe mailing list
Sframe@ietf.org https://www.ietf.org/mailman/listinfo/sframe
--000000000000afefd705cb962af9--