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

"Cullen Jennings (fluffy)" <> Wed, 16 November 2016 03:50 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id A0232129575; Tue, 15 Nov 2016 19:50:21 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -116.017
X-Spam-Status: No, score=-116.017 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=-1.497, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_WHITELIST=-100] 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 YbrM_WXWOarE; Tue, 15 Nov 2016 19:50:20 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id D9A16129441; Tue, 15 Nov 2016 19:50:19 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;;; l=17056; q=dns/txt; s=iport; t=1479268220; x=1480477820; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=EPtcxTBys8NfWeRWXCUi8N938zOG3a5kVHRbC8fJ3/o=; b=a7D1F9m7Pc4tFBOLa9IbSh9hUVkjrPGyaskfHAC4MG3L0ROOQ9EFB5hO n3/hvIq24Q9ASNAnJniZS5Lot/5eyEiJYWRUHIIP6XVA9Buzigwt0YaKH QYBPkofuwnYnt/kpYNCxbrKrpthSRYCds1EZaesb4HDT4o/0Pn7RWPi5c 8=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-AV: E=Sophos;i="5.31,646,1473120000"; d="scan'208,217";a="348815989"
Received: from ([]) by with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 16 Nov 2016 03:50:18 +0000
Received: from ( []) by (8.14.5/8.14.5) with ESMTP id uAG3oIbY002004 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 16 Nov 2016 03:50:18 GMT
Received: from ( by ( with Microsoft SMTP Server (TLS) id 15.0.1210.3; Tue, 15 Nov 2016 22:50:18 -0500
Received: from ([]) by ([]) with mapi id 15.00.1210.000; Tue, 15 Nov 2016 22:50:18 -0500
From: "Cullen Jennings (fluffy)" <>
To: Stephen Farrell <>
Thread-Topic: [MMUSIC] Stephen Farrell's No Objection on draft-ietf-mmusic-sdp-mux-attributes-14: (with COMMENT)
Thread-Index: AQHSP7yLycYMKIqvRkmpC/Rq138QlA==
Date: Wed, 16 Nov 2016 03:50:17 +0000
Message-ID: <>
References: <> <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: []
Content-Type: multipart/alternative; boundary="_000_C723B99A074F4EA19B65636B5C3A83D8ciscocom_"
MIME-Version: 1.0
Archived-At: <>
Cc: "Cullen Jennings \(fluffy\)" <>, "" <>, mmusic WG <>, "" <>, The IESG <>
Subject: Re: [MMUSIC] Stephen Farrell's No Objection on draft-ietf-mmusic-sdp-mux-attributes-14: (with COMMENT)
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 16 Nov 2016 03:50:22 -0000

text way down at bottom

On Oct 31, 2016, at 6:50 AM, Stephen Farrell <<>> wrote:


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 <<>>

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


- 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?