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. <kmigoe@xxxxxxx> 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.