Re: [Sframe] Negotiating SFrame/RTP in SDP

[Bernard Aboba <[e-mail]>]

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 <
[e-mail]> 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 <[e-mail]> 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:<frame|packet> [<keying>]
>>
>> 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
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/sframe
>>
> --
> Sframe mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/sframe
>