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

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

Return-Path: <fluffy@cisco.com>
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A0232129575; Tue, 15 Nov 2016 19:50:21 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -116.017
X-Spam-Level:
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: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YbrM_WXWOarE; Tue, 15 Nov 2016 19:50:20 -0800 (PST)
Received: from alln-iport-8.cisco.com (alln-iport-8.cisco.com [173.37.142.95]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D9A16129441; Tue, 15 Nov 2016 19:50:19 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; 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-Anti-Spam-Result: =?us-ascii?q?A0DsAQCR1itY/5JdJa1dHAEBBAEBCgEBg?= =?us-ascii?q?nM2DgEBAQEBH4FYB403qWGCDoIHhiMCggY/FAECAQEBAQEBAWIohGIBAQR5EAI?= =?us-ascii?q?BCDsEBzIUEQIEDgWIbLQHi2QBAQEBAQEBAQEBAQEBAQEBAQEBAQEciDmCXYQ7g?= =?us-ascii?q?z6CMAWIUJFxAZBhgW+Edok9jUeECQEeN4EEHIMjHBiBRXKFYIEugQwBAQE?=
X-IronPort-AV: E=Sophos;i="5.31,646,1473120000"; d="scan'208,217";a="348815989"
Received: from rcdn-core-10.cisco.com ([173.37.93.146]) by alln-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 16 Nov 2016 03:50:18 +0000
Received: from XCH-RTP-004.cisco.com (xch-rtp-004.cisco.com [64.101.220.144]) by rcdn-core-10.cisco.com (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 xch-rtp-004.cisco.com (64.101.220.144) by XCH-RTP-004.cisco.com (64.101.220.144) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Tue, 15 Nov 2016 22:50:18 -0500
Received: from xch-rtp-004.cisco.com ([64.101.220.144]) by XCH-RTP-004.cisco.com ([64.101.220.144]) with mapi id 15.00.1210.000; Tue, 15 Nov 2016 22:50:18 -0500
From: "Cullen Jennings (fluffy)" <fluffy@cisco.com>
To: Stephen Farrell <stephen.farrell@cs.tcd.ie>
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: <C723B99A-074F-4EA1-9B65-636B5C3A83D8@cisco.com>
References: <147747540682.18851.267971327825992233.idtracker@ietfa.amsl.com> <CAMRcRGRQYoVuurAuiy9tJFcJ_Kt3fR_4Cr9oStZiWcCNdvwGog@mail.gmail.com> <09c0816b-40b2-a3ea-cbdb-265eca5d66cc@cs.tcd.ie>
In-Reply-To: <09c0816b-40b2-a3ea-cbdb-265eca5d66cc@cs.tcd.ie>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.70.231.60]
Content-Type: multipart/alternative; boundary="_000_C723B99A074F4EA19B65636B5C3A83D8ciscocom_"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/mmusic/K78cWKP0SeQyMugPTIBHQSdbuqI>
Cc: "Cullen Jennings \(fluffy\)" <fluffy@cisco.com>, "mmusic-chairs@ietf.org" <mmusic-chairs@ietf.org>, mmusic WG <mmusic@ietf.org>, "draft-ietf-mmusic-sdp-mux-attributes@ietf.org" <draft-ietf-mmusic-sdp-mux-attributes@ietf.org>, The IESG <iesg@ietf.org>
Subject: Re: [MMUSIC] Stephen Farrell's No Objection on draft-ietf-mmusic-sdp-mux-attributes-14: (with COMMENT)
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group <mmusic.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mmusic>, <mailto:mmusic-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/mmusic/>
List-Post: <mailto:mmusic@ietf.org>
List-Help: <mailto:mmusic-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mmusic>, <mailto:mmusic-request@ietf.org?subject=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 <stephen.farrell@cs.tcd.ie<mailto:stephen.farrell@cs.tcd.ie>> wrote:


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 <stephen.farrell@cs.tcd.ie<mailto:stephen.farrell@cs.tcd.ie>>
wrote:

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

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


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?