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

[Emad Omara <[e-mail]>]

Thanks Bernard. The SFrame draft intentionally avoided any RTP
dependencies, but as referenced a generic frame marking extension could be
used to pass the media metadata in plaintext (but authenticated). Of course
the RTP header ext should be HBH encrypted.  Regarding packetization, yes a
generic RTP packetizer will be used since the media will be encrypted. The
frame marking ext will be used to define the frame boundaries.

That being said, we need a 2nd draft for SFrame-RTP integration to cover
this topic and potentially other topics as well, which I promised I will
work on sometime soon :-)

On Mon, Aug 31, 2020 at 12:27 PM Bernard Aboba <[e-mail]>
wrote:

> 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]
>>> <+46%2010%20714%2082%2087>
>>> > > > > Torshamnsgatan 23           | Mobile [phone]
>>> <+46%2073%20094%2090%2079>
>>> > > > > SE-164 80 Stockholm, Sweden | mailto:
>>> [e-mail]
>>> > > > >
>>> ----------------------------------------------------------------------
>>> > > > >
>>> > > > >
>>> --
>>> Cheers
>>>
>>> Magnus Westerlund
>>>
>>>
>>> ----------------------------------------------------------------------
>>> Networks, Ericsson Research
>>> ----------------------------------------------------------------------
>>> Ericsson AB                 | Phone  [phone]
>>> <+46%2010%20714%2082%2087>
>>> Torshamnsgatan 23           | Mobile [phone]
>>> <+46%2073%20094%2090%2079>
>>> SE-164 80 Stockholm, Sweden | mailto: [e-mail]
>>> ----------------------------------------------------------------------
>>>
>>>
>>> --
>> Sframe mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/sframe
>>
>