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

[Stephen Farrell <[e-mail]>]

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]>
> wrote:
> 
>> Stephen Farrell has entered the following ballot position for
>> draft-ietf-mmusic-sdp-mux-attributes-14: No Objection
>>
>> When responding, please keep the subject line intact and reply to all
>> email addresses included in the To and CC lines. (Feel free to cut this
>> introductory paragraph, however.)
>>
>>
>> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
>> for more information about IESG DISCUSS and COMMENT positions.
>>
>>
>> The document, along with other ballot positions, can be found here:
>> https://datatracker.ietf.org/doc/draft-ietf-mmusic-sdp-mux-attributes/
>>
>>
>>
>> ----------------------------------------------------------------------
>> 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.


> 
> 
> 
> 
>>
>> - 5.36 vs. 5.39: It wasn't clear to me why these have
>> different rules - can you explain?
>>
>>
>>
> [Suhas] : It looks like both the fingerprint (Section 5.36) and
> zrtp-hash(5.39) attributes have the same Multiplexing category of TRANSPORT
> assigned and thus follow the same rules. Am i missing something here ?
> 

In the ZRTP case you have a MUST and level == M. In the other
there's no MUST and it has level == B. At this point I forget
what those level things mean though;-)

S.

> 
>> _______________________________________________
>> mmusic mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/mmusic
>>
>