Re: [Sframe] Intended DISPATCH outcome / charter

[Emad Omara <[e-mail]>]

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 <[e-mail]> 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.
>
> 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]
>> <+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
>