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> wrote:

>
>
> On 10 Aug 2021, at 21:54, Richard Barnes <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
>
> (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.
>
>
> I filed https://github.com/w3c/webrtc-encoded-transform/issues/114 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>
>> *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.
>>
>
>