Re: [MMUSIC] Stephen Farrell's No Objection on draft-ietf-mmusic-sdp-mux-attributes-14: (with COMMENT)

["Cullen Jennings (fluffy)" <[e-mail]>]

text way down at bottom


On Oct 31, 2016, at 6:50 AM, Stephen Farrell <[e-mail]<mailto:[e-mail]>> wrote:


Hiya,

On 26/10/16 23:47, Suhas Nandakumar wrote:
Hello Stephen

   Thanks for the review . please see inline.

On Wed, Oct 26, 2016 at 2:50 AM, Stephen Farrell <[e-mail]<mailto:[e-mail]>>
wrote:

Stephen Farrell has entered the following ballot position for
draft-ietf-mmusic-sdp-mux-attributes-14: No Objection

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------


- 4.5 and 5.7: What if the different a=crypto lines
specify different strength ciphersuites? Wouldn't it be
better to pick the strongest or to say they MUST be the
same (as is done in 5.35)? If picking the first is the
right answer then maybe warn folks to not put a stronger
ciphersuite anywhere else?



[Suhas]:  I did think about it some more and I am not sure the mux draft
opens up an vulnerability in this scenario.
For example, Even with the IDENTICAL category, the Offerer can include a
weak cipher in all the m=lines and thus force the Answerer to select the
weak one or have the Answerer reject the Offer. I am not sure if making it
iDENTICAL would help us guard against the wrong cipher selection.
.
In the TRANSPORT scenario, if the Answerer selected the m=line with a weak
cipher the Offerer has 2 options a) Don't include the weak cipher b) Do
another Offer/Answer with the modified list (with strong ciphers or
inactive media)

Please advise ..

It's less an issue of creating a vulnerability as it is of
making it easier for people to end up in a situation where
they think they have better security than is in fact the
case. I think experience shows that disallowing differences
of that kind is a good plan. But I could understand if it
was the case that allowing such discrepancies made it easier
to get interop in some cases. I don't know if that latter
is the case.


Typically the SDP Offer would have the same level of security in each m-section. In rare cases where the audio and video  gets terminated on different equipment, and the audio / video might get upgraded at different times and thus have different security levels. Even then, typically both audio and video have the lower level until both can be moved to higher level. But bundle would never be used in the case where the audio and video was split because they would be on different IPs and thus not bundled.

So here my straw man suggestion ... it seems like the right place to mention this is in the security consideration for bundle and point out that if you offer multiple m-lines that are bundled, the recommendation is for the offers and answer to have the same security level or put the m-line with the highest level security first so that if bundle is selected, we get the strongest security.

I know that's a bit hand wavy but does that make sense?