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

From: Christer Holmberg <[email-masked]>
Date: Tue, 30 Apr 2013 12:16:36 +0000

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

---

From: Martin Thomson <[email-masked]>
Date: Tue, 30 Apr 2013 11:50:01 -0700

> 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…

Yes, I hadn't considered that, but it's another reason to have
different keys :)  Since this is only the bundling side that is
affected, this can be addressed with a security considerations note to
the effect that the bundler, who has chosen to use the same key across
m= lines, MUST NOT select the same SSRC for those sessions.  I think
that's an easy thing to do.

Still, even without special measures chances are that you wont pick
colliding SSRCs.  Though the odds are not really in your favor given
the size of the space you chose from; it doesn't take many sessions
before it happens to someone.

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

That would be reasonable too.  I probably wouldn't bother with the
change in practice (see above), but MAY == good.