Re: [secdir] Secdir review of draft-ietf-mmusic-duplication-grouping-03

Vincent Roca <vincent.roca@inria.fr> Wed, 20 November 2013 07:59 UTC

Return-Path: <vincent.roca@inria.fr>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 10DBD1AE394; Tue, 19 Nov 2013 23:59:12 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.075
X-Spam-Level:
X-Spam-Status: No, score=-7.075 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.525] autolearn=ham
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 gVTSOJhc7F6q; Tue, 19 Nov 2013 23:59:10 -0800 (PST)
Received: from mail3-relais-sop.national.inria.fr (mail3-relais-sop.national.inria.fr [192.134.164.104]) by ietfa.amsl.com (Postfix) with ESMTP id 91DA61AE391; Tue, 19 Nov 2013 23:59:09 -0800 (PST)
X-IronPort-AV: E=Sophos;i="4.93,735,1378850400"; d="scan'208";a="36660710"
Received: from demeter.inrialpes.fr ([194.199.24.102]) by mail3-relais-sop.national.inria.fr with ESMTP/TLS/AES128-SHA; 20 Nov 2013 08:59:02 +0100
Mime-Version: 1.0 (Apple Message framework v1085)
Content-Type: text/plain; charset="iso-8859-1"
From: Vincent Roca <vincent.roca@inria.fr>
In-Reply-To: <2816F03A-D44B-4408-A86A-26585F6B583D@cisco.com>
Date: Wed, 20 Nov 2013 08:59:01 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <8A6B6759-BF9A-4C7B-9DBB-FEE3929CC7BD@inria.fr>
References: <D71EFBF3-3BD3-4782-9AAB-4489B068C946@inria.fr> <2816F03A-D44B-4408-A86A-26585F6B583D@cisco.com>
To: "Ali C. Begen" <abegen@cisco.com>
X-Mailer: Apple Mail (2.1085)
Cc: "<draft-ietf-mmusic-duplication-grouping@tools.ietf.org>" <draft-ietf-mmusic-duplication-grouping@tools.ietf.org>, IESG <iesg@ietf.org>, "secdir@ietf.org" <secdir@ietf.org>
Subject: Re: [secdir] Secdir review of draft-ietf-mmusic-duplication-grouping-03
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/secdir/>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 20 Nov 2013 07:59:12 -0000

Hi Ali,


Le 18 nov. 2013 à 16:22, Ali C. Begen (abegen) a écrit :

> Hi Vincent,
> 
> On Nov 18, 2013, at 4:58 PM, Vincent Roca <vincent.roca@inria.fr> wrote:
> 
>> IMHO, the document is Almost ready.
>> 
>> My main comment WRT this I-D is the following:
>> 
>> 1- There is no reference to RFC4566 (SDP) security section! This is a pity
>> as the security considerations are very well addressed in this RFC, much
>> better than in the present I-D I would say.
>> Additionally, I don't think that adding duplication grouping to SDP changes
>> so much the situation WRT SDP security, so this is one more reason to
>> have this reference.
> 
> We can add this, no worries. I think we simply followed RFC 5888 in this section but your point is taken.

I've missed this RFC. Anyway, a reference to RFC 4566 is fine as it details
security aspects with a reasonable level of details.


>> Otherwise:
>> 
>> 2- The authors say that "there is a weak threat". Is the threat weak in the
>> sense it is unlikely to happen (why?), or is it weak in the sense it will have
>> limited consequences? In any case, I would be in favor of removing
>> "weak" altogether.
> 
> It means it is unlikely to happen because if someone can modify the SDP for changing the grouping, it can actually do much worse things by changing other things. 

Of course, but "weak" remains ambiguous (unless you say more) and in fact
not that important.


>> 3- Since we are now all aware of the necessity of making pervasive
>> monitoring more  complex, it could be useful to say that having some
>> confidentiality is recommended (in addition to integrity and authentication
>> of course). This is not discussed in RFC4566 (but it was published in 2006),
>> so it's worth mentioning it in this I-D (no need to say much).
> 
> Personally I dont think anything we say in this draft will have any impact in this regard but I can add this when doing the revision.

Yes, but focusing on integrity and source authentication only suggests
that confidentiality is not an important service. That's my point. A single
sentence saying that it can sometimes be useful to use a secure, encrypted
channel or transport to carry the SDP is sufficient.

Cheers,

   Vincent