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

Suhas Nandakumar <suhasietf@gmail.com> Wed, 26 October 2016 22:47 UTC

Return-Path: <suhasietf@gmail.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 47321129594; Wed, 26 Oct 2016 15:47:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 sdNUIaRKYpyz; Wed, 26 Oct 2016 15:47:12 -0700 (PDT)
Received: from mail-yb0-x234.google.com (mail-yb0-x234.google.com [IPv6:2607:f8b0:4002:c09::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9E0FB129457; Wed, 26 Oct 2016 15:47:12 -0700 (PDT)
Received: by mail-yb0-x234.google.com with SMTP id f97so8942425ybi.1; Wed, 26 Oct 2016 15:47:12 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=hQyhf/EQyfyPszl/7Ijo3RKqpPEk9NW4SlqoEAwLuPw=; b=oP7pPDzDh7xKPRtFUdsQJIlqx63V3Oq2sky8hUha+31SBuAXHoDufF/KKIW9nMU/1l bdV2DvXvqPT8B9GPd+AyCcOgvO83x+Z0ByH0hXPQIFwBDCkASWhAWNf4ZoVB69JSyMtk RgrG83eoEi2jormbOIGeeuahpGK5DLng/cz59+4Olfhs1Sclus46RW3GFcHGJ9vJ16fu kmZk1y5RbCVldC6ebLS96rT2IAEUvX3QvBKYtcRCe6TnfisXHDiLXphQ6ooqxUu0v/Ds keu12Xk5Gl2IBFnI4eh7HcMZbI22KhoKcAmU0PxPxPnLxJo0eC63/sdV2uEd3C1GE0Ht TF4w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=hQyhf/EQyfyPszl/7Ijo3RKqpPEk9NW4SlqoEAwLuPw=; b=iai6jWgS9iTtz0P7qyLR9W7QlcOKtjOdc1wKotX0XCIWcWsaMx2Jw74yg/6eat27iA z7/RfIsNbqByEaLy3JsZCerCWgHxgdYHpcL7H7d7NkRYf019c0hWZ244uqStIEmiHK5L yJHarGSvXUfcUmAWr+FVF01ejKSt/wAaDyd2V5nT8bmb24PNBCi8sB2wVsJB1IzqPatk IebRDcMwbkGGaojY7m4Lu6PGvAVFIju+SpgOHbqJeNAYU/yc5630GZtU2RjsUfMmjlxp cBCOytCWL7LhoJyqwtvkZD/+ErK/8LVAZXgoTGuQ4OkC3xV8VGzyqcLwBLq2ff4nR2h2 ix9A==
X-Gm-Message-State: ABUngvcADjlIMuN6aRZNW18zQd4Kch43ZOvPMOF1hzkHcfz+UO8LoIPO0OfTavoaoigiQt6U7trbXKM6aG9F4Q==
X-Received: by 10.37.171.74 with SMTP id u68mr3720560ybi.191.1477522028831; Wed, 26 Oct 2016 15:47:08 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.129.158.73 with HTTP; Wed, 26 Oct 2016 15:47:08 -0700 (PDT)
In-Reply-To: <147747540682.18851.267971327825992233.idtracker@ietfa.amsl.com>
References: <147747540682.18851.267971327825992233.idtracker@ietfa.amsl.com>
From: Suhas Nandakumar <suhasietf@gmail.com>
Date: Wed, 26 Oct 2016 15:47:08 -0700
Message-ID: <CAMRcRGRQYoVuurAuiy9tJFcJ_Kt3fR_4Cr9oStZiWcCNdvwGog@mail.gmail.com>
To: Stephen Farrell <stephen.farrell@cs.tcd.ie>
Content-Type: multipart/alternative; boundary=94eb2c184bb8ad34c8053fcc6758
Archived-At: <https://mailarchive.ietf.org/arch/msg/mmusic/5k6kt7wpEt00LySRIe5LrJvp48A>
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: Wed, 26 Oct 2016 22:47:14 -0000

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




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


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