Re: [secdir] SECDIR review of draft-ietf-mmusic-sdp-mux-attributes-13

[Chris Lonvick <[e-mail]>]

Hi Suhas,

I hope your vacation was good.  :-)

These edits look appropriate.

Best regards,
Chris

On 8/25/16 1:07 PM, Suhas Nandakumar (snandaku) wrote:
>
> ​Hello Chris
>
>
>    Apologies for the delayed response ( was on vacation :-) )
>
>
>    Please see inline for responses to your review comments (marked 
> with [[Suhas]] )​
>
>
> Thanks
>
> Suhas Nandakumar
>
>
> ------------------------------------------------------------------------
> *From:* Chris Lonvick <[e-mail]>
> *Sent:* Sunday, July 24, 2016 7:41 AM
> *To:* [e-mail]; [e-mail]; 
> [e-mail]
> *Subject:* Re: SECDIR review of draft-ietf-mmusic-sdp-mux-attributes-13
> Apologies for the duplication - resending to the right alias.
>
> On 7/24/16 9:39 AM, Chris Lonvick wrote:
>> Hi,
>>
>> I have reviewed this document as part of the security directorate's 
>> ongoing effort to review all IETF documents being processed by the 
>> IESG. These comments were written primarily for the benefit of the 
>> security area directors. Document editors and WG chairs should treat 
>> these comments just like any other last call comments.
>>
>> I've been rather busy and haven't had time to thoroughly review this 
>> document. But I did look at the Security Considerations section and 
>> will recommend that some additions be made. The Security 
>> Considerations section says, "This document does not add any new 
>> security considerations beyond the existing considerations in the 
>> RFCs for protocols that are being multiplexed together. " (First 
>> paragraph.) I believe that it would be helpful to readers and 
>> implementers if the specification were to give pointers to RFCs for 
>> protocols that are being multiplexed together, and their security 
>> considerations.
>>
>> [[Suhas]] - On further internal discussions, we think the above 
>> paragraph needs to be rephrased as below to be specific on the goals 
>> of this specification.
>> "This document does not add any new security considerations beyond 
>> the existing considerations in the RTP  RFCs (RFC3550 and 
>> RFC3711) referenced by this specification."
>>
>>
>> The section continues by saying, "The ways that SRTP streams are 
>> keyed is not believed to create any two-time pad vulnerability for 
>> the currently defined SRTP keying mechanism." (Second paragraph.) I 
>> may not have seen it but I don't believe that this document specifies 
>> keying for SRTP streams, but only references RFC4567 (Section 5.35) 
>> and RFC4572 (Section 5.36). If that's the case, then this document 
>> doesn't need to opine about possible vulnerabilities in that area; 
>> leave it to those or subsequent documents to make that analysis. 
>> [[Suhas]] - Agree with you. I will delete the sentence.
>>
>> It would be appropriate to reiterate that the CAUTION category may 
>> produce some problems.
>> [[Suhas]] - Sure, will add something in the lines of below 
>> "When multiplexing SDP attributes with the category "CAUTION", the 
>> implementations should be aware of possible issues as described in 
>> this specification"
>>
>>
>> For completeness, it may be good to include pointers to other mmusic 
>> and SDP documents that have addressed security aspects. A statement 
>> of how that may apply to this specification would be appropriate. I 
>> don't think this would need to be detailed.
>>
>> [[Suhas]] How about something on the lines below.
>> "The primary security for RTP including the way it is used here is 
>> described in RC3550 and RFC3711" .
>>
>> Best regards,
>> Chris
>