Re: [MMUSIC] Review of draft-ietf-mmusic-sdp-bundle-negotiation-32 - Magnus' comments - MID security

[Eric Rescorla <[e-mail]>]

On Thu, Oct 13, 2016 at 2:09 AM, Magnus Westerlund <
[e-mail]> wrote:

> Den 2016-10-13 kl. 02:51, skrev Eric Rescorla:
>
>>
>>
>> On Wed, Oct 12, 2016 at 12:54 PM, Christer Holmberg
>> <[e-mail] <mailto:[e-mail]>>
>> wrote:
>>
>>     Hi,____
>>
>>     __ __
>>
>>     My intention was not to claim we have consensus. I just wanted to
>>     put forward some text to see whether it’s something we can work
>> on.____
>>
>>     __ __
>>
>>     Or, would you prefer to not saying anything?
>>
>>
>> I don't think we need to say anything normative.
>>
>>
> Can you please be a bit more constructive here?
>

I think I am being constructive. I'm trying to get the draft finished, and
this seems to be poorly motivated.


I hope you are not disagreeing with a RECOMMEND for source authentication
> at least? Having third party attackers being able to change the MID on path
> that is a quite serious attack, so integrity and source authentication I
> think is well motivated.
>

There seem to be two cases:

1. You're using SRTP (and this should also include SRTCP).
2. You're not using SRTP.

In case #1, then the MID should be integrity protected because it's part of
the packet. If not, then I don't think a partial solution helps.


Regarding the aspects regarding privacy and information leakage. You
> previously indicated that you agree that we should at least avoid
> structured MIDs to avoid that implementation specifics or hardware
> addresses of source devices leaks this way.


No, that's not what I said. Rather, I said:

"The first of these seems addressable by guidance about how to construct
these IDs. I note that we
have only very limited guidance on how to construct ICE ufrag/passwords...."

If you think this kind of identifier-generation tracking is an issue, I
would suggest doing a broader survey
first, rather than focusing on this case.

-Ekr

This would mean that BUNDLE should contain guidance on how to construct
> them so this is avoided. This is currently not included. I have no problem
> with including such recommendations. Do you have a proposal for how to
> construct them?
>
> When we come to the last aspect regarding confidentiality protection of
> the MID identifiers I can understand the hesitance over this. For some use
> cases I agree the information leakage is in principal zero, as the fact
> that the streams are there are present through SSRCs, PTs etc. However,
> especially for multiple  streams originating from a endpoint, rather than a
> conference mixer, this do exposes information. Here the above discussed
> recommendations do matters for what information can be leaked. For example
> if we would sequentially assign identifers, then we exposes the potential
> sub-selection of streams the signalling agrees on at the RTP layer. If we
> use random values this exposure can be avoid.
>
> I proposed encryption as method that would ensure that we had random
> identifiers of good properties. But, what is your proposal for how these
> identifiers should be construct to minimize the exposure of information?
>
> I also asked the question if there was issues with encrypting this from a
> functional perspective? Unless I receive an answer I will assume not, and
> that it is primarily a hesitant to start using RFC6904.
>
> From my perspective, lets settle the guidance for construction, then we
> can document what the potential remaining risks are in the security
> consideration. I personally think it is more important to document the
> risks than absolutely have the RFC2119 recommendation here.
>
>
> Cheers
>
> Magnus Westerlund
>
> ----------------------------------------------------------------------
> Services, Media and Network features, Ericsson Research EAB/TXM
> ----------------------------------------------------------------------
> Ericsson AB                 | Phone  [phone]
> Färögatan 6                 | Mobile [phone]
> SE-164 80 Stockholm, Sweden | mailto: [e-mail]
> ----------------------------------------------------------------------
>
>