Re: [Sframe] Intended DISPATCH outcome / charter

[Richard Barnes <[e-mail]>]

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 <
[e-mail]> wrote:

> 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
> > 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
> --
> Cheers
>
> Magnus Westerlund
>
>
> ----------------------------------------------------------------------
> Networks, Ericsson Research
> ----------------------------------------------------------------------
> Ericsson AB                 | Phone  [phone]
> Torshamnsgatan 23           | Mobile [phone]
> SE-164 80 Stockholm, Sweden | mailto: [e-mail]
> ----------------------------------------------------------------------
>
>
>