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

From: Magnus Westerlund <[email-masked]>
Date: Wed, 5 Aug 2020 14:34:13 +0000

Hi,

I want to make one high level comments on the proposed charter for SFRAME. 

The charter attempts to be transport agnostic. However, we know there are
certain use cases this solution needs to support. And I think one of the hardest
from a security perspective is the multi-party centralised one with one or more
SFUs. Based on the significant discussion we had in PERC around threat model, I
think this charter do need to have in its description work to explicitly develop
the threat model as well describe which aspects of the threat model that one can
address. For example I think the security threat of media delay which is an
interesting variant of "replay" attack that exist for real-time media
conversation where there are logic that selects what to forward. 

Cheers

Magnus Westerlund

On Fri, 2020-07-31 at 13:15 -0400, Richard Barnes wrote:
> The link Emad posted should allow for comments, so please feel free to comment
> directly on the doc.
> 
> Or you can reply with comments here and we'll get them incorporated.
> 
> On Thu, Jul 30, 2020 at 5:59 PM Ben Campbell <[email-masked]> wrote:
> > Hi everyone,
> > 
> > We had a good discussion on SFrame in the dispatch meeting, and a lot of
> > interest in progressing it. The chairs would love it if we can get some
> > discussion of the proposed charter (below) now, while it’s still fresh in
> > people’s minds. If we don’t see feedback to the contrary within a couple of
> > weeks (let’s call that 14 Aug), we will hand it over to the ART ADs.
> > 
> > Thanks!
> > 
> > Ben.
> > 
> > > On Jul 27, 2020, at 12:34 PM, Emad Omara <
> > > emadomara=[email-masked]> wrote:
> > > 
> > > Hi dispatch,
> > > 
> > > Following up on the discussion we had this morning in IETF 108 dispatch
> > > session about SFrame, it seems there is enough interest to form a focused
> > > WG for this work. 
> > > 
> > > Richard Barnes proposed this charter for the WG. Please take a look and
> > > feel free to comment on the doc directly and propose other changes as
> > > well.
> > > 
> > > Thanks
> > > Emad
> > > _______________________________________________
> > > dispatch mailing list
> > > [email-masked]
> > > https://www.ietf.org/mailman/listinfo/dispatch
> > 
> > _______________________________________________
> > dispatch mailing list
> > [email-masked]
> > https://www.ietf.org/mailman/listinfo/dispatch
> 
> _______________________________________________
> dispatch mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dispatch
-- 
Cheers

Magnus Westerlund 

----------------------------------------------------------------------
Networks, Ericsson Research
----------------------------------------------------------------------
Ericsson AB                 | Phone  +46 10 7148287
Torshamnsgatan 23           | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden | mailto: [email-masked]
----------------------------------------------------------------------

---

From: Sergio Garcia Murillo <[email-masked]>
Date: Wed, 5 Aug 2020 22:15:24 +0200

But shouldn't the "delayed media" attack still be transport agnostic? I 
mean, this can happen on QUIC and WebRTC SFUs.

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.

Best regards
Sergio

---

From: Magnus Westerlund <[email-masked]>
Date: Thu, 6 Aug 2020 08:56:16 +0000

Hi,

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

> 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

---

From: Emad Omara <[email-masked]>
Date: Thu, 6 Aug 2020 11:02:26 -0700

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 <
[email-masked]> wrote:

> <+46%2010%20714%2082%2087>
> <+46%2073%20094%2090%2079>

---

From: Alexandre GOUAILLARD <[email-masked]>
Date: Sat, 8 Aug 2020 11:51:05 +0800

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=
[email-masked]> wrote:

> Sframe mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sframe
>

---

From: Richard Barnes <[email-masked]>
Date: Wed, 12 Aug 2020 11:11:33 -0400

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

---

From: Ben Campbell <[email-masked]>
Date: Tue, 18 Aug 2020 16:55:26 -0500

Hi Everyone,

I have not seen any comments that suggest this should not proceed. Therefore, we are dispatching the current proposed charter[1] to the ART ADs to move things forward. There will be additional opportunities for feedback during the IESG review process.

[1] https://docs.google.com/document/d/10rG8nAR0U6cBBPffzXnLaPPYL4uzxYViAvgiSezoa7o/edit?usp=sharing

Thanks!

Ben.

> On Jul 30, 2020, at 4:57 PM, Ben Campbell <[email-masked]> wrote:
> 
> Hi everyone,
> 
> We had a good discussion on SFrame in the dispatch meeting, and a lot of interest in progressing it. The chairs would love it if we can get some discussion of the proposed charter (below) now, while it’s still fresh in people’s minds. If we don’t see feedback to the contrary within a couple of weeks (let’s call that 14 Aug), we will hand it over to the ART ADs.
> 
> Thanks!
> 
> Ben.
> 
>> On Jul 27, 2020, at 12:34 PM, Emad Omara <emadomara=[email-masked]> wrote:
>> 
>> Hi dispatch,
>> 
>> Following up on the discussion we had this morning in IETF 108 dispatch session about SFrame, it seems there is enough interest to form a focused WG for this work. 
>> 
>> Richard Barnes proposed this charter for the WG. Please take a look and feel free to comment on the doc directly and propose other changes as well.
>> 
>> Thanks
>> Emad

---

From: Barry Leiba <[email-masked]>
Date: Tue, 18 Aug 2020 19:23:05 -0400

I will put this into the datatracker and tag it for Murray; he’ll handle it
when he returns from vay-cay.

Barry

On Tue, Aug 18, 2020 at 5:55 PM Ben Campbell <[email-masked]> wrote:

> Hi Everyone,
>
>
>
> I have not seen any comments that suggest this should not proceed.
> Therefore, we are dispatching the current proposed charter[1] to the ART
> ADs to move things forward. There will be additional opportunities for
> feedback during the IESG review process.
>
>
>
> [1]
> https://docs.google.com/document/d/10rG8nAR0U6cBBPffzXnLaPPYL4uzxYViAvgiSezoa7o/edit?usp=sharing
>
>
>
> Thanks!
>
>
>
> Ben.
>
>
>
> feel free to comment on the doc directly and propose other changes as well.
>
> >>
>
> >> Thanks
>
> >> Emad
>

---

From: Magnus Westerlund <[email-masked]>
Date: Mon, 31 Aug 2020 14:06:07 +0000

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:
> The SFrame specification will detail the specific security properties that the
> encapsulation provides, and discuss their implications under common usage
> scenarios / threat models.
> """
> 
> > - there are multiple usage of media over the internet, e.g. conferencing and
> > streaming/broadcast
> > PERC was, by design, limited to RTP and to Conferencing. Many other use case
> > coul benefit from Enhanced Privacy.
> > 
> > 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.
> > 
> > On Fri, Aug 7, 2020 at 2:02 AM Emad Omara <
> > > 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
> > > 
-- 
Cheers

Magnus Westerlund

---

From: Richard Barnes <[email-masked]>
Date: Mon, 31 Aug 2020 11:40:09 -0400

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 <
[email-masked]> wrote:

> Frame
> > > > > > But shouldn't the "delayed media" attack still be transport
> agnostic?
> > > > > I
> > > > > 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
> > > > > My main point is that SFRAME actually needs to discuss the threat
> model
> > > > > for the
> > > > > - 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
> > > > > - Confidentiality when group membership changes: So will SFRAME
> keying
> > > > > support a
> > > > > media and one rekey the media session key for each time the
> membership
> > > > > changes?
> > > > > 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
> > > > > invovled endpoints and SFU to accomplish mitigations. And thus
> also what
> > > > > the
> > > > > that and document what migitagtions that exists in the SFRAME
> layer and
> > > > > what

---

From: Bernard Aboba <[email-masked]>
Date: Mon, 31 Aug 2020 12:27:07 -0700

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 <[email-masked]> wrote:

>> > > > > SFRAME gaps to know give a reasonably strong mitigation against
>> any
>> > > > > third party
>> > > > > will still have the semi-trusted SFUs and all the rest of the
>> third
>> > > > > parties in
>> > > > > issues needs to be more clearly discussed as the RTP transport
>> can have
>> > > > > affected

---

From: Emad Omara <[email-masked]>
Date: Mon, 31 Aug 2020 15:14:11 -0700

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 <[email-masked]>
wrote:

>>> > > > > 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
>>> > > > > sequence. In a point to point scenario one can correlate
>>> transport
>>> > > > > losses with
>>> > > > > 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
>>> > > > > use case where only the current set of members in a conference
>>> can
>>> > > > > decrypt the
>>> > > > > give this topic full focus. The solution will of necessity need
>>> to
>>> > > > > reference