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

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

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

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>
> *Sent:* Tuesday, August 10, 2021 2:59 AM
> *To:* Bernard Aboba <Bernard.Aboba@microsoft.com>; Sergio Garcia Murillo <
> sergio.garcia.murillo@cosmosoftware.io>
> *Cc:* public-webrtc@w3.org <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>
> 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%7C1a0e2c95866e431861e508d95bcc7722%7C72f988bf86f141af91ab2d7cd011db47%7C0%7C0%7C637641756012822732%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=k9gFqGA3AoJK3ZJgWkZXjOeJTslSwr6DwK1%2B4j4PWME%3D&reserved=0>
>
>
> Thanks for filing this issue.
> Let’s dig into that there.
>