Hi Kevin, For the record, based on your comments I now consider the SSRC text to be a minor issue rather than a major one.
Comments inline (again, deleting parts that seem closed) On Sep 18, 2014, at 10:30 AM, Igoe, Kevin M. <[email protected]> wrote: [...] > > Does the "source" in each source mean the synchronization source? > > These terms get a little slippery, bit what I mean is the gear responsible > for encrypting outgoing data. Let’s call this the originating box. > > I'm not entirely sure I follow you, but I read this to mean you avoid the > need for central management of SSRCs by not sharing keys between more than > one originator? (that is Assuming so (and my next comment will make no sense > otherwise): Wouldn't it make more sense to discourage shared keys, since such > sharing would create a need for central ssrc management, rather than suggest > ssrc management in the first place? > > Yes, but sadly key management is out-of-scope for srtp. Also a stronger verb > that > than “discourage” is needed, more like “prohibit”. I don't think the fact that key management is out-of-scope for srtp in general prevents you from offering guidance security critical parts. > > Or do you expect communities to actually implement central ssrc management? > > If there is a small network of devices sharing the same key, say a video > conference with > a handful of participants. One could envision giving each box entering the > conference > a unique SSRC prefix it uses for any SSRCs it needs to create, once again > localizing the > SSRC management (save for the task of handing out SSRC prefixes). > > The bottom line is that there are several ways to mitigate the need for > centralized > SSRC magament. I agree with you that the key management based approach is > far and > away the cleanest approach. > > My sole concern is not reusing an (SRTP, key) pair. Any robust mechanism > (i.e. > not probabilistic) that achieves this goal is acceptable. I guess my problem is that I took the text as written to suggest that centralized ssrc management was expected to be the "normal" case. I think it would be perfectly reasonable to say something to the effect of "... MUST not share keys unless a secure mechanism is used to guarantee that SSRC values never collide." I realize that is logically similar to "MUST have [ssrc coordination] in order to share keys", but the spin is a bit different. _______________________________________________ Gen-art mailing list [email protected] https://www.ietf.org/mailman/listinfo/gen-art
