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

[Chris Lonvick <[e-mail]>]

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.
>
> 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.
>
> It would be appropriate to reiterate that the CAUTION category may 
> produce some problems.
>
> 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.
>
> Best regards,
> Chris