Re: [Sframe] [dispatch] SFRame Next Steps (was SFrame proposed WG charter)

[Bernard Aboba <[e-mail]>]

Richard said:

"in the most obvious SFrame+SRTP case, there's a division of labor between
the two protocols, "

[BA] There is also an interaction between E2E encryption and packetization
that needs to be captured somewhere. In SFrame, the packetization model is
potentially different from PERC, because the SFrame packetizer may not have
visibility into the E2E encrypted payload (e.g. the packetizer may not have
access to the cleartext payload).  The implication is that the information
needed to packetize the E2E encrypted frame (e.g. the metadata) needs to be
provided to the packetizer.  This info must be sufficient to fill in the
RTP header fields as well as RTP header extensions, including those RTP
header extensions used by an SFU for forwarding (e.g. frame-marking or
Dependency Descriptor).

I'd note that the current SFrame draft does not address this yet, except
for a figure including a "payload header" in section 1.  It is my
understanding that the "Payload Header" represents info provided in the
clear (such as the VP8 header), which is needed by the packetizer.
Implementations that have encrypted this field or have not provided what
was expected (e.g. attempts to utilize the H.264/AVC codec) have
encountered E2E encryption failures.

One approach to addressing this is to define a "generic packetizer" for a
transport that will be able to packetize and depacketize the E2E encrypted
frame in any codec.  If that work is indeed needed, then it should be
described somewhere.

On Mon, Aug 31, 2020 at 8:41 AM Richard Barnes <[e-mail]> wrote:

> Hi Magnus,
>
> I think the intent here is to have a mechanism that provides a subset of
> the security properties required for a given scenario, but which can be
> augmented with additional mechanisms to provide the rest.  For example,
> even in the most obvious SFrame+SRTP case, there's a division of labor
> between the two protocols, where SFrame only protects content, and SRTP
> also protects the RTP header and guards against reply by network attackers.
>
> So in a sense it is an intersection (in that it does something that is
> needed by all the use cases), but it might need other things to provide all
> the properties you need in a given scenario.
>
> --Richard
>
> On Mon, Aug 31, 2020 at 10:06 AM Magnus Westerlund <
> [e-mail]> wrote:
>
>> Hi,
>>
>> Thanks for working on addressing my comments when on vacation.
>>
>> I think you mostly arravied at a good place. However, I would like to
>> make one
>> remark about the added language.
>>
>> When it comes to threat models it can't be the intersection of threats
>> across
>> those that occur in the intended usages, it needs to be the union of
>> threats.
>> The formulation added implies intersection to me.
>>
>> Cheers
>>
>> Magnus
>>
>> On Wed, 2020-08-12 at 11:11 -0400, Richard Barnes wrote:
>> > Hey all,
>> >
>> > I agree that all of this stuff is valuable to capture somewhere.  In the
>> > interest of keeping the charter fairly succinct, I've added the
>> following:
>> >
>> > """
>> > The SFrame specification will detail the specific security properties
>> that the
>> > encapsulation provides, and discuss their implications under common
>> usage
>> > scenarios / threat models.
>> > """
>> >
>> > With that, I think that all the comments we've gotten so far have been
>> > addressed.
>> >
>> > --Richard
>> >
>> >
>> > On Fri, Aug 7, 2020 at 11:51 PM Alexandre GOUAILLARD <
>> > [e-mail]> wrote:
>> > > guys,
>> > >
>> > > sorry for jumping in so late, quarantine here is very strict.
>> > >
>> > > We had long discussions about this specific point ahead of the draft
>> > > submission.
>> > > We had reached the following consensus:
>> > > - there are multiple usage of media over the internet, e.g.
>> conferencing and
>> > > streaming/broadcast
>> > > - they have very different threat/trust models, with different
>> solutions
>> > > implemented today (transport layer E / E2EE / DRM / Encrypted Media
>> > > Extentions / ...)
>> > > - they all can benefit from SFrame
>> > >
>> > > PERC was, by design, limited to RTP and to Conferencing. Many other
>> use case
>> > > coul benefit from Enhanced Privacy.
>> > >
>> > > We concluded that it would be better to keep SFrame (the media
>> encryption
>> > > part, equivalent to PERC double conceptually), and to have separated
>> > > documents that describe the threat models and the corresponding key
>> > > exchange, signaling and system level decision for each use case. Emad
>> had
>> > > taken an action item for example to make two additional documents to
>> > > describe the Video Conferencing use case, and how SFrame could be
>> used in
>> > > conjunction with MLS to address that specific use case. Someone else
>> could
>> > > take the different use case of the Browsers (which have a specific
>> trust
>> > > model) and make a document showing how SFrame con work with
>> Insertable Frame
>> > > API (and likely some more) to address that use case. CoSMo is
>> interested in
>> > > doing the same thing for Real-Time streaming/Broadcasting.
>> > >
>> > > I think it is a more reasonable approach as, even spending a lot of
>> time
>> > > brainstorming with everyone around the tabel including bernard, we
>> couldn't
>> > > think about one solution to fit all the different "media over
>> internet"'s
>> > > threat model. In my mind, each case should first have an informal
>> document
>> > > to define scope and threat model, and subsequent document to define
>> the
>> > > corresponding specifications.
>> > > - Secure Conferencing Threat model (emad and co.)
>> > > - Secure Conferencing Signalling using MLS (emad and co.)
>> > > - Secure Conferencing using MLS In the browser (contributed by w3c
>> people)
>> > >
>> > > Magnus, what do you think?
>> > >
>> > > Regards,
>> > >
>> > > Dr. ALex.
>> > >
>> > >
>> > >
>> > > On Fri, Aug 7, 2020 at 2:02 AM Emad Omara <
>> > > emadomara=[e-mail]> wrote:
>> > > > Thanks Magnus. I like the idea to explicitly call out the threat
>> model, I
>> > > > think it will be good foundations that control all future design
>> > > > decisions, however I'm not sure if the charter is the right place
>> to call
>> > > > this out. I'd recommend having a separate document that describes
>> the
>> > > > system architecture, goals and threat model. What do you think?
>> > > >
>> > > > Emad
>> > > >
>> > > > On Thu, Aug 6, 2020 at 1:56 AM Magnus Westerlund <
>> > > > [e-mail]> wrote:
>> > > > > Hi,
>> > > > >
>> > > > > On Wed, 2020-08-05 at 22:15 +0200, Sergio Garcia Murillo wrote:
>> > > > > > But shouldn't the "delayed media" attack still be transport
>> agnostic?
>> > > > > I
>> > > > > > mean, this can happen on QUIC and WebRTC SFUs.
>> > > > >
>> > > > > Sorry if I gave the impression that it is not transport agnostic.
>> It is
>> > > > > use case
>> > > > > dependent, any use case that isn't point to point, where there is
>> more
>> > > > > than one
>> > > > > entity that can intentionally remove SFRAME creating gaps in the
>> SFRAME
>> > > > > sequence. In a point to point scenario one can correlate transport
>> > > > > losses with
>> > > > > SFRAME gaps to know give a reasonably strong mitigation against
>> any
>> > > > > third party
>> > > > > removing SFRAMEs or delaying them. That is much harder in a
>> centralized
>> > > > > conference with one or more SFU.
>> > > > >
>> > > > > >
>> > > > > > Anyway, I agree that while SFrame is transport agnostic, the
>> chapter
>> > > > > > should not ignore the interactions with webrtc/quic and we must
>> > > > > ensure
>> > > > > > that we provide a complete working solution regardless of the
>> > > > > transport.
>> > > > > > If we identify that any further working items are required for
>> a
>> > > > > > particular transport, we should at liaise with the appropriate
>> > > > > working
>> > > > > > group for providing a solution.
>> > > > >
>> > > > > My main point is that SFRAME actually needs to discuss the threat
>> model
>> > > > > for the
>> > > > > use cases it intendes to solve. And the mitigation can potentially
>> > > > > include
>> > > > > functionality on the transport level. But the risks to media
>> security in
>> > > > > centralized conferencing needs to be discussed. And centralized
>> > > > > conferencing
>> > > > > will still have the semi-trusted SFUs and all the rest of the
>> third
>> > > > > parties in
>> > > > > addition to the end-points.
>> > > > >
>> > > > > Also what properties one have around end-points invited into the
>> > > > > conference has
>> > > > > a number of question around security properties that needs to be
>> > > > > discussed and
>> > > > > documented. Some examples that I know are relevant:
>> > > > >
>> > > > > - Source authentication: SRTP unless one use TESLA (which isn't
>> really
>> > > > > used)
>> > > > > does only provided the property: Someone that has the key sent
>> this. One
>> > > > > don't
>> > > > > know that it comes from a particular endpoint.
>> > > > >
>> > > > > - Confidentiality when group membership changes: So will SFRAME
>> keying
>> > > > > support a
>> > > > > use case where only the current set of members in a conference can
>> > > > > decrypt the
>> > > > > media and one rekey the media session key for each time the
>> membership
>> > > > > changes?
>> > > > > PERC do support this, will SFRAME?
>> > > > >
>> > > > > There are likely more questions that needs discussion. The PERC
>> > > > > discussion is a
>> > > > > good starting point, but I think when going transport agnostic
>> some of
>> > > > > the
>> > > > > issues needs to be more clearly discussed as the RTP transport
>> can have
>> > > > > affected
>> > > > > how it was discussed, and what reliance on existing mechanism.
>> Which for
>> > > > > SFRAME
>> > > > > likely require a general discussion and then requirements on the
>> > > > > transport and
>> > > > > invovled endpoints and SFU to accomplish mitigations. And thus
>> also what
>> > > > > the
>> > > > > risks are of having no mitigation in place.
>> > > > >
>> > > > > I would really propose that SFRAME is chartered with publishing a
>> > > > > security
>> > > > > consideration and threat model document that is seperate from the
>> > > > > solution to
>> > > > > give this topic full focus. The solution will of necessity need to
>> > > > > reference
>> > > > > that and document what migitagtions that exists in the SFRAME
>> layer and
>> > > > > what
>> > > > > becomes requirements on the transport.
>> > > > >
>> > > > > Cheers
>> > > > >
>> > > > > Magnus Westerlund
>> > > > >
>> > > > >
>> > > > >
>> ----------------------------------------------------------------------
>> > > > > Networks, Ericsson Research
>> > > > >
>> ----------------------------------------------------------------------
>> > > > > Ericsson AB                 | Phone  [phone]
>> > > > > Torshamnsgatan 23           | Mobile [phone]
>> > > > > SE-164 80 Stockholm, Sweden | mailto:
>> [e-mail]
>> > > > >
>> ----------------------------------------------------------------------
>> > > > >
>> > > > >
>> --
>> Cheers
>>
>> Magnus Westerlund
>>
>>
>> ----------------------------------------------------------------------
>> Networks, Ericsson Research
>> ----------------------------------------------------------------------
>> Ericsson AB                 | Phone  [phone]
>> Torshamnsgatan 23           | Mobile [phone]
>> SE-164 80 Stockholm, Sweden | mailto: [e-mail]
>> ----------------------------------------------------------------------
>>
>>
>> --
> Sframe mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/sframe
>