Re: [MMUSIC] 10 BUNDLE questions: Same SDES key for multiple m- lines?

[Christer Holmberg <[e-mail]>]

Hi,

>> As people have indicated, it prevents a two-time pad attack, and that is also the only reason I can think of. My suggestion is to keep the restriction in list 1 and 2. But, if someone OBJECTS to this, please indicate so.
>
> The two-time pad thing is bogus, unless you are using shim (so that you can reuse SSRCs).
>
> I think that I would like to OBJECT to this.  It is possible to perform decrypt after demux, and there are no inherent problems.
>
> I initially wasn't that concerned with people taking this position, because I figured that it would be better to allow for some flexibility in the order of operations.  However, it makes multiplexing translators harder to build.
>
> It's not a strong objection. After all, we are all in the business of accelerating the heat death of the universe.
>
>>> 6. If you start with a m= line with one SDES config (e.g. 32-bit 
>>> MAC), and then BUNDLE with another SDES line with a different (non 
>>> overlapping) SDES config (e.g. 80-bit MAC), what happens? (assume 
>>> fail)
>>
>> People have indicated that this would be a failure, and I have seen no one indicate otherwise. But, if someone OBJECTS to this, please indicate so.
>
> See above.

Regarding using the same SDES key, it is important to remember that, if there is a fallback (ie the remote endpoint does not support BUNDLE, and the SDP answer will contain different ports), there will be different RTP sessions, in which case two-time pad becomes an issue.

So, one way forward would be:

1. In the first offer, when it is still unknown whether the remote endpoint supports BUNDLE, use different SDES keys.

2. In the second offer, if the remote endpoint indicated support of BUNDLE, allow switching to a single SDES key.

Regards,

Christer