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

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?

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.

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.).
________________________________
From: Richard Barnes <rlb@ipv.sx>
Sent: Wednesday, August 11, 2021 12:31 PM
To: youenn <youenn@apple.com>
Cc: Bernard Aboba <Bernard.Aboba@microsoft.com>; sergio.garcia.murillo@cosmosoftware.io <sergio.garcia.murillo@cosmosoftware.io>; public-webrtc@w3.org <public-webrtc@w3.org>
Subject: Re: [EXTERNAL] Call for Consensus (CfC): WebRTC Encoded Transform as a WG Draft



On Tue, Aug 10, 2021 at 10:55 AM Youenn Fablet <youenn@apple.com<mailto:youenn@apple.com>> wrote:


On 10 Aug 2021, at 21:54, Richard Barnes <rlb@ipv.sx<mailto:rlb@ipv.sx>> wrote:

Hi all,

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.)

On Tue, Aug 10, 2021 at 4:05 AM Bernard Aboba <Bernard.Aboba@microsoft.com<mailto:Bernard.Aboba@microsoft.com>> wrote:
"Bernard, please correct me if I am wrong, my understanding of the current situation at IETF is that:
- There is consensus for SFrame as a binary format.
- There is consensus on how to apply SFrame to audio content over RTP.
- There is no consensus on how to apply SFrame to video content over RTP."

This matches my understanding.  Where "binary format" means "how you frame/encrypt a chunk of data", and that chunk might be a packet payload or a frame.  The only point where SFrame and SPacket diverge is multi-packet video frames.


[BA]  At IETF 110 AVTCORE meeting, there were objections to the idea of a generic packetizer of encrypted frames transported over RTP.  The objectors felt that existing packetizations might have advantages (e.g. allowing slices to be decoded). Because most of the objections used video examples, I suspect that these objections related more to video than audio, but I can't say for sure.

At IETF 111 AVTCORE meeting, Sergio presented an alternative to SFrame (SPacket).  In this approach, encryption is done after packetization, not before. So this allows the existing packetization to be retained, although overhead is increased.  However, since the original objectors to SFrame weren't present at the meeting, it is hard to say whether SPacket addressed their objections or not.

So now there are two proposals for the transport format over RTP.  It is a bit confusing because so far there is only one implemented transport for SFrame (RTP) and in that transport, it is not clear whether there is consensus for it.

With respect to the statements above, given the lack of a consensus call on those issues, I don't think we can draw a conclusion.  The first topic (SFrame format) is on the agenda for discussion at the SFRame interim so I suspect there are issues that still need to be resolved.

If you have ideas on how to move things along within IETF, it might be good for you to post them there.  For example, getting a reading on the consensus questions you pose above might be helpful in clarifying things.

I concede that I missed the AVTCORE discussion.  I didn't realize that SFrame was on the agenda there, and will go back and review the discussion.  (Thanks to Sergio for presenting the SPacket side of things.)

Nonetheless, I don't think this group necessarily needs to have a resolution on the SFrame vs. SPacket question in order to proceed to FPWD.  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.

I'm actually more concerned that the shape of the API is still focused on manual keying; the MLS-SFrame integration that assures unique per-sender keys would require a different API surface.  But that could also be handled by adding an MLSSFrameTransform later.

I filed https://github.com/w3c/webrtc-encoded-transform/issues/114<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fw3c%2Fwebrtc-encoded-transform%2Fissues%2F114&data=04%7C01%7CBernard.Aboba%40microsoft.com%7Cc6721818334d460958d408d95cfeb765%7C72f988bf86f141af91ab2d7cd011db47%7C0%7C0%7C637643071364005248%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=WDtDdBNI2TSDWq%2BPhqXPCyOWgoKtwEdpd0WjSu3b8dA%3D&reserved=0> to keep track of that issue.
I would hope we do not need a MLSSFrameTransform so it would be good to get your feedback on the API surface that you think is necessary sooner rather than later.

Thanks, Youenn.  I added some notes on the issue.  To summarize here: We can probably get by without an MLSSFrameTransform in the short run (using WebCrypto operations on non-extractable keys), but in the longer run, we'll get better assurance if we have some way to connect an MLS context and an SFrameTransform.  But we can handle that once we have an actual MLS context to talk about.

--RLB



Personally, I don't have a very strong opinion on whether the WG could adopt this document.  Slightly positive because it seems like a step on the path back to having WebRTC keys be inaccessible to JS, even with E2E encryption.  Mainly just wanted to say that I wouldn't view the SFrame/SPacket discussion as a blocker.

--Richard




________________________________
From: Youenn Fablet <youenn@apple.com<mailto:youenn@apple.com>>
Sent: Tuesday, August 10, 2021 2:59 AM
To: Bernard Aboba <Bernard.Aboba@microsoft.com<mailto:Bernard.Aboba@microsoft.com>>; Sergio Garcia Murillo <sergio.garcia.murillo@cosmosoftware.io<mailto:sergio.garcia.murillo@cosmosoftware.io>>
Cc: public-webrtc@w3.org<mailto:public-webrtc@w3.org> <public-webrtc@w3.org<mailto:public-webrtc@w3.org>>
Subject: [EXTERNAL] Re: Call for Consensus (CfC): WebRTC Encoded Transform as a WG Draft

+Sergio with whom we worked on the presentation of SFrame and SPacket at last AVTCore meeting.

Bernard, please correct me if I am wrong, my understanding of the current situation at IETF is that:
- There is consensus for SFrame as a binary format.
- There is consensus on how to apply SFrame to audio content over RTP.
- There is no consensus on how to apply SFrame to video content over RTP.

On 10 Aug 2021, at 00:23, Bernard Aboba <Bernard.Aboba@microsoft.com<mailto:Bernard.Aboba@microsoft.com>> wrote:

(Chair hat off).

I object to promoting this document to WG Draft, due to concerns about Section 4 (SFrameTransform).  Within the IETF, proposals for SFrame over RTP have been controversial and so far have not been adopted by a WG.

At IETF 111, an alternative to SFRame over RTP (SPacket) was proposed.  It therefore seems premature to me to introduce an API that is specific to a protocol proposal that may not gain traction.

I have filed a GitHub issue here:
Protocol Reference for SFrameTransform · Issue #112 · w3c/webrtc-encoded-transform (github.com)<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fw3c%2Fwebrtc-encoded-transform%2Fissues%2F112&data=04%7C01%7CBernard.Aboba%40microsoft.com%7Cc6721818334d460958d408d95cfeb765%7C72f988bf86f141af91ab2d7cd011db47%7C0%7C0%7C637643071364015188%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=7OtwMYlx4SeCvnNiWQIh6qiBu4zLDa4NpfSj%2B3Hali8%3D&reserved=0>

Thanks for filing this issue.
Let’s dig into that there.