Re: [Sframe] Intended DISPATCH outcome / charter

[Alexandre GOUAILLARD <[e-mail]>]

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=
[e-mail]> 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.
>
> 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
>>
> --
> Sframe mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/sframe
>