ietf
[Top] [All Lists]

Re: Gen-ART LC Review of draft-ietf-avtcore-srtp-aes-gcm-14

2014-09-18 16:17:30
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(_at_)nsa(_dot_)gov> 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.


<Prev in Thread] Current Thread [Next in Thread>