Subject: [Sframe] Intended DISPATCH outcome / charter

From: Richard Barnes <[email-masked]>
Date: Tue, 21 Jul 2020 16:46:27 -0400

Hey all,

I see that SFrame is on the DISPATCH agenda.  Great idea, thanks to
whomever arranged that.

In my experience, DISPATCH proposals have gone more smoothly when they've
had a proposed resolution in mind.  Recall that the DISPATCH outcomes are
roughly:

0. Do nothing
1. Existing working group
2. AD sponsorship
3. New WG

My inclination is that this work is probably about the right size for its
own small, focused working group.  Toward that goal, I've gone ahead and
sketched a charter for the WG here:

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

I think that captures everything I think is important to get done here.
But please feel free to comment there (or here) if you think the scope is
wrong.

Cheers,
--Richard

---

From: Alexandre GOUAILLARD <[email-masked]>
Date: Wed, 22 Jul 2020 07:52:30 +0800

Thanks richard for doing this.
This looks interesting.
A naive question, is the march 2021 deadline not too tight? for example if
we decide to add a document for the video conference use case to show how
MLS could be used, will it extend the deadline, have its own deadline (per
document) or have to fit into the march 2021 deadline?

On Wed, Jul 22, 2020 at 4:46 AM Richard Barnes <[email-masked]> wrote:

> https://docs.google..com/document/d/10rG8nAR0U6cBBPffzXnLaPPYL4uzxYViAvgiSezoa7o/edit?usp=sharing
> <https://docs.google.com/document/d/10rG8nAR0U6cBBPffzXnLaPPYL4uzxYViAvgiSezoa7o/edit?usp=sharing>
>
> --
> Sframe mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sframe
>

---

From: Magnus Westerlund <[email-masked]>
Date: Wed, 22 Jul 2020 11:10:22 +0000

Hi,

Some questions about this charter proposal. It seems to to say simply that the
WG will define an encryption and authentication encapsulation of a media ADU. 

It will not take into consideration of how it can be used in any existing real-
time media distrubution system, such as transported over RTP signalled by SIP,
WebRTC, RTSP etc. Or for that matter how one sticks it in an ISO based media
file format that dominates the streaming world, and also live streaming. 

Shouldn't at least this work decide if the content of a SFRAME will contain
information to identify the format of the protected ADU, or if that is required
to be done externally, or support both? 

I think this is part of a fundamental quesiton about the utility of the format
and how one can use it. Having something internally also then raises the
question of what namespace to use. 

Also how are other meta data that is relevant to prevent attack such as replay
are this included?

I did note that the referenced draft do discuss signatures also. Is this
intended to be included or not. With SRTP with the exception of the TESLA cipher
SRTP has not really had the property that a receiver can know which sender
within a conference that actually sent the media, only that it was someone
within the group that had the group key. As signature likely has additional
requirement on the key-exchange protocol as it would need to provide assymetric
keys for the signature verification for each participant rather than just group
keying material I think if this intended to be included should be mentioned
explicitly.

Cheers

Magnus

On Tue, 2020-07-21 at 16:46 -0400, Richard Barnes wrote:
> Hey all,
> 
> I see that SFrame is on the DISPATCH agenda.  Great idea, thanks to whomever
> arranged that.
> 
> In my experience, DISPATCH proposals have gone more smoothly when they've had
> a proposed resolution in mind.  Recall that the DISPATCH outcomes are roughly:
> 
> 0. Do nothing
> My inclination is that this work is probably about the right size for its own
> small, focused working group.  Toward that goal, I've gone ahead and sketched
> a charter for the WG here:
> 
> 
> 
> I think that captures everything I think is important to get done here.  But
> please feel free to comment there (or here) if you think the scope is wrong.
> 
> Cheers,
> --Richard
-- 
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: Richard Barnes <[email-masked]>
Date: Wed, 22 Jul 2020 09:55:11 -0400

I would rate March 2021 as aggressive, but potentially achievable.  On the
one hand, deadlines for IETF WGs are not really enforced.  On the other
hand, since folks are already shipping code, this seemed like work that
could move a bit more quickly than average.

---

From: Richard Barnes <[email-masked]>
Date: Wed, 22 Jul 2020 12:52:01 -0400

Hey Magnus,

Re signaling / formats: Every byte we add here is pure overhead, so I think
my opening bid would be to document all the parameters that the senders and
receivers need to agree on, but punt on actually negotiating/signaling them
as much as possible.

Re replay: I don't think anything new is needed in the data format (w.r.t.
current draft), since there's already a counter.  But it would be good to
recommend that implementations enforce an anti-replay window.

Re signatures: I would be comfortable leaving signatures out of scope /
reserving for future work.  While I agree it would be cool to have the
additional security property they would provide (per-sender
authentication), it's not clear to me that it needs to be part of the
initial version here.

--Richard

On Wed, Jul 22, 2020 at 7:10 AM Magnus Westerlund <
[email-masked]> wrote:

> whomever
> https://docs.google.
> .com/document/d/10rG8nAR0U6cBBPffzXnLaPPYL4uzxYViAvgiSezoa7o/edit?usp=sharing
> >
> But

---

From: Emad Omara <[email-masked]>
Date: Wed, 22 Jul 2020 16:12:31 -0700

Thanks Richard for the write up. I'd prefer to have a new WG if possible to
track this work, as we discussed before the current draft needs a few more
tweaks and we need a couple more documents  in order to have a complete
solution.

Note that I only have 20 minutes on Monday, so not sure if this will be
enough to have such discussion, but I can just do a quick overview for the
draft and take the next steps discussions on the mailing list. What do you
guys think?

On Wed, Jul 22, 2020 at 9:52 AM Richard Barnes <[email-masked]> wrote:

> Hey Magnus,
>
> Re signaling / formats: Every byte we add here is pure overhead, so I
> think my opening bid would be to document all the parameters that the
> senders and receivers need to agree on, but punt on actually
> negotiating/signaling them as much as possible.
>
>> > I think that captures everything I think is important to get done
>> here..  But
>> <+46%2010%20714%2082%2087>
>> <+46%2073%20094%2090%2079>

---

From: Alexandre GOUAILLARD <[email-masked]>
Date: Thu, 23 Jul 2020 07:40:17 +0800

listing the documents you plan to produce, and adjusting the charter
proposal would help i believe.

On Thu, Jul 23, 2020 at 7:12 AM Emad Omara <emadomara=
[email-masked]> wrote:

> Thanks Richard for the write up. I'd prefer to have a new WG if possible
> to track this work, as we discussed before the current draft needs a few
> more tweaks and we need a couple more documents  in order to have a
> complete solution.
>
>> Re replay: I don't think anything new is needed in the data format
>> (w.r.t. current draft), since there's already a counter.  But it would be
>> good to recommend that implementations enforce an anti-replay window.
>>
>>> here...  But

---

From: Magnus Westerlund <[email-masked]>
Date: Thu, 23 Jul 2020 08:51:04 +0000

On Wed, 2020-07-22 at 12:52 -0400, Richard Barnes wrote:
> Hey Magnus,
> 
> Re signaling / formats: Every byte we add here is pure overhead, so I think my
> opening bid would be to document all the parameters that the senders and
> receivers need to agree on, but punt on actually negotiating/signaling them as
> much as possible.

Ok, I can understand the stance on saying the signalling of the format is for
the transport to carry with the actual SFRAME. However, there is the other
aspect of this question about formats, is if SFRAME will have its own set of
specifications for application data unit formats, and a name space for it.
Encapsulating an RTP payload format is of course possible, and then use that
format name space, but may not be efficient in all cases and duplicates some
functionality that an RTP payload format for SFRAME will need. I want to
understand if the WG intended to create a new name space for format identifiers?

> recommend that implementations enforce an anti-replay window.

The problematic thing for those who lived through the PERC discussion is that we
have a system where both original sender as well as the SFU may cause
interruption in the transmission schedule. Thus, it is hard to determine if a
gap is reasonable or not and there exist some potentials for attackers to hold
and later play out packets seconds or minutes later. For example if I would say
"no   no" then the attcker could let the first "no" go though. Hold the second
"no" and release that later where it might cause confusion or change the
intended meaning of the conversation. It would not be replay, only delaying. 

Maybe my point is that the WG need to be clear what the security properties and
threat models considered are. 

> additional security property they would provide (per-sender authentication),
> it's not clear to me that it needs to be part of the initial version here.

Just trying to understand scope here. Appears something people need to form a
consensus about in which direction the WG should go here. 

Cheers

Magnus

> > had
> > own
-- 
Cheers

Magnus Westerlund