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

[Magnus Westerlund <[e-mail]>]

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

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. 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]
----------------------------------------------------------------------