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

"Suhas Nandakumar (snandaku)" <> Thu, 25 August 2016 18:07 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 3E7E512D563; Thu, 25 Aug 2016 11:07:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -15.068
X-Spam-Status: No, score=-15.068 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id kYiFeRC14mGi; Thu, 25 Aug 2016 11:07:56 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 8C11E12D575; Thu, 25 Aug 2016 11:07:56 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;;; l=8897; q=dns/txt; s=iport; t=1472148476; x=1473358076; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=ocL512yrKhDxJWjQEGHLZjk3aeu8SuCf62DEPqZxlOw=; b=dxaAWwe6W7yCoe90tGSPGTIQ1UTQLk5VWX4p7dEkjOF2DR1Ci0TSJHpY NEFKaaEPRTGtLAjPkNVHftJN/2LVRektjhQarMzxlRUZPgDtpi4+zYWQa ao9ZORKaffvlYU+CPlkDOaBgxM+mUDDXqx/o7ODjgXEjrQmJCo7+E53MR Y=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-AV: E=Sophos;i="5.28,576,1464652800"; d="scan'208,217";a="141720159"
Received: from ([]) by with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 25 Aug 2016 18:07:55 +0000
Received: from ( []) by (8.14.5/8.14.5) with ESMTP id u7PI7teB008929 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 25 Aug 2016 18:07:55 GMT
Received: from ( by ( with Microsoft SMTP Server (TLS) id 15.0.1210.3; Thu, 25 Aug 2016 13:07:54 -0500
Received: from ([]) by ([]) with mapi id 15.00.1210.000; Thu, 25 Aug 2016 13:07:54 -0500
From: "Suhas Nandakumar (snandaku)" <>
To: Chris Lonvick <>, "" <>, "" <>, "" <>
Thread-Topic: SECDIR review of draft-ietf-mmusic-sdp-mux-attributes-13
Thread-Index: AQHR5bltj7pCDEeP606GPrcWxOR4VKBaJ8l1
Date: Thu, 25 Aug 2016 18:07:54 +0000
Message-ID: <>
References: <>,<>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: []
Content-Type: multipart/alternative; boundary="_000_147214847447298410ciscocom_"
MIME-Version: 1.0
Archived-At: <>
Cc: "Cullen Jennings (fluffy)" <>, "Flemming Andreasen (fandreas)" <>, Bo Burman <>, "Suhas Nandakumar (snandaku)" <>
Subject: Re: [secdir] SECDIR review of draft-ietf-mmusic-sdp-mux-attributes-13
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Security Area Directorate <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 25 Aug 2016 18:07:58 -0000

?Hello Chris

   Apologies for the delayed response ( was on vacation :-) )

   Please see inline for responses to your review comments (marked with [[Suhas]] )?


Suhas Nandakumar

From: Chris Lonvick <>
Sent: Sunday, July 24, 2016 7:41 AM
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:

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,