Re: [EXTERNAL] Call for Consensus (CfC): WebRTC Encoded Transform as a WG Draft

> On 12 Aug 2021, at 00:21, Bernard Aboba <Bernard.Aboba@microsoft.com> wrote:
> 
> Richard said: 
> 
> "
>> 
>> I think I'm one of the folks who has expressed concerns over SFrame (vs. SPacket), so let me chime in here.  For context, Webex is using SPacket for its new MLS-based E2E encryption.
>> 
>> https://www.cisco.com/c/en/us/solutions/collateral/collaboration/white-paper-c11-744553.html <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.cisco.com%2Fc%2Fen%2Fus%2Fsolutions%2Fcollateral%2Fcollaboration%2Fwhite-paper-c11-744553.html&data=04%7C01%7CBernard.Aboba%40microsoft.com%7Cc6721818334d460958d408d95cfeb765%7C72f988bf86f141af91ab2d7cd011db47%7C0%7C0%7C637643071364005248%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=uNnGhEAGxf9A37p7oHJm%2B5QYD46tI96mVgxoH7yq8F4%3D&reserved=0>
>> 
>> (The whitepaper says SFrame because it is the same encoding as in the SFrame draft, but it is applied per-packet.)
> "
> 
> [BA] The WebEx implementation of SPacket is a native application, rather than utilizing the WebRTC encoded transform API, correct? 

I’ll let Richard answer to the exact question.

I wanted to say though that the issues we are encountering with SFrame are related to its interaction with RTP.
SFrameTransform, being a TransformStream, is not tied to RTP.
It is perfectly feasible today to do something like MediaStreamTrack -> WebCodecs -> SFrameTransform -> WebTransport for instance.

> Richard said: 
> 
> "
>> 
>> It seems like the API/stack and the protocol could co-evolve here. ISTM that even if the specs aren't quite in order, SFrame and SPacket are both well understood enough to allow prototyping.  In the worst case, if that never resolves, it seems like you could have an SFrameTransformOptions interface that had a mode switch.
> "
> 
> [BA]  While the stack and protocol are evolving quickly, I'd prefer not to add a native transform specific to a protocol that hasn't been adopted by an IETF WG, particularly if that method can't accommodate automatic key management. That is just inviting interoperability problems. 

I’ll beef up https://github.com/w3c/webrtc-encoded-transform/issues/112 <https://github.com/w3c/webrtc-encoded-transform/issues/112> with these thoughts.
I added some thoughts on these issues to identify potential actions on the spec you would like to see happening. Can you have a look at the propositions?

As of key management, I believe Richard and I think there is a reasonable path forward to build on the existing SFrameTransform so that it works well with MLS.
There would be a need for a new MLS API (yet to be developed) and some API to integrate SFrameTransform and MLS, either on one side or the other, or maybe both.

> However, options might make sense where the processing is done in JS (e.g. to allow either SPacket or SFrame to be implemented in JS).  However, the status of the JS API should be clearly indicated and the limitations should be explained in a note and/or in the Security Considerations section (e.g. manual key management, keys exposed to JS, etc.).


That makes sense, I filed https://github.com/w3c/webrtc-encoded-transform/issues/115 <https://github.com/w3c/webrtc-encoded-transform/issues/115>.