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

Stephen Farrell <stephen.farrell@cs.tcd.ie> Sun, 30 October 2016 21:51 UTC

Return-Path: <stephen.farrell@cs.tcd.ie>
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 E584A129493; Sun, 30 Oct 2016 14:51:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.798
X-Spam-Level:
X-Spam-Status: No, score=-5.798 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.497, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cs.tcd.ie
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 bcMqYWik1brj; Sun, 30 Oct 2016 14:51:00 -0700 (PDT)
Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AFF821293FF; Sun, 30 Oct 2016 14:51:00 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id C4C48BE2E; Sun, 30 Oct 2016 21:50:58 +0000 (GMT)
X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie
Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9iiqyaukfNtP; Sun, 30 Oct 2016 21:50:57 +0000 (GMT)
Received: from [10.87.48.210] (95-45-153-252-dynamic.agg2.phb.bdt-fng.eircom.net [95.45.153.252]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id BA73BBE2C; Sun, 30 Oct 2016 21:50:56 +0000 (GMT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1477864257; bh=yl2MoO5dA6pW5alZVdWT3Iju0k7wxIXJVkJiOe8oh0M=; h=Subject:To:References:Cc:From:Date:In-Reply-To:From; b=IWET5joOSCoKXkP7+neSWQmaAoD3VwJytR5Di2EF017rialRd4KVDu1bvJU0Ey4Nn JyqSA9CVobkmZhgPBUHVDA7e4A3G5Df25aHtd0RoWGuxVpVC/qNmrutVRW8tHRO84I aqVDbhcSVKWIJROJzRRZYgQl5jv00UZvF2tlKtEk=
To: Suhas Nandakumar <suhasietf@gmail.com>
References: <147747540682.18851.267971327825992233.idtracker@ietfa.amsl.com> <CAMRcRGRQYoVuurAuiy9tJFcJ_Kt3fR_4Cr9oStZiWcCNdvwGog@mail.gmail.com>
From: Stephen Farrell <stephen.farrell@cs.tcd.ie>
Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url=
Message-ID: <09c0816b-40b2-a3ea-cbdb-265eca5d66cc@cs.tcd.ie>
Date: Sun, 30 Oct 2016 21:50:57 +0000
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0
MIME-Version: 1.0
In-Reply-To: <CAMRcRGRQYoVuurAuiy9tJFcJ_Kt3fR_4Cr9oStZiWcCNdvwGog@mail.gmail.com>
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms080203000307070208090004"
Archived-At: <https://mailarchive.ietf.org/arch/msg/mmusic/vPldRUcdDYXdm4ZZm-oOQCgEkCk>
Cc: mmusic-chairs@ietf.org, draft-ietf-mmusic-sdp-mux-attributes@ietf.org, The IESG <iesg@ietf.org>, mmusic WG <mmusic@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: Sun, 30 Oct 2016 21:51:02 -0000

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>
> wrote:
> 
>> Stephen Farrell has entered the following ballot position for
>> draft-ietf-mmusic-sdp-mux-attributes-14: No Objection
>>
>> When responding, please keep the subject line intact and reply to all
>> email addresses included in the To and CC lines. (Feel free to cut this
>> introductory paragraph, however.)
>>
>>
>> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
>> for more information about IESG DISCUSS and COMMENT positions.
>>
>>
>> The document, along with other ballot positions, can be found here:
>> https://datatracker.ietf.org/doc/draft-ietf-mmusic-sdp-mux-attributes/
>>
>>
>>
>> ----------------------------------------------------------------------
>> 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.


> 
> 
> 
> 
>>
>> - 5.36 vs. 5.39: It wasn't clear to me why these have
>> different rules - can you explain?
>>
>>
>>
> [Suhas] : It looks like both the fingerprint (Section 5.36) and
> zrtp-hash(5.39) attributes have the same Multiplexing category of TRANSPORT
> assigned and thus follow the same rules. Am i missing something here ?
> 

In the ZRTP case you have a MUST and level == M. In the other
there's no MUST and it has level == B. At this point I forget
what those level things mean though;-)

S.

> 
>> _______________________________________________
>> mmusic mailing list
>> mmusic@ietf.org
>> https://www.ietf.org/mailman/listinfo/mmusic
>>
>