Re: [secdir] [payload] sec-dir review of draft-ietf-payload-rtp-opus-08

"DRAGE, Keith (Keith)" <keith.drage@alcatel-lucent.com> Tue, 07 April 2015 16:16 UTC

Return-Path: <keith.drage@alcatel-lucent.com>
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 773021B379A; Tue, 7 Apr 2015 09:16:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.91
X-Spam-Level:
X-Spam-Status: No, score=-6.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] 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 UiHV9xBbj0lc; Tue, 7 Apr 2015 09:16:01 -0700 (PDT)
Received: from smtp-fr.alcatel-lucent.com (fr-hpgre-esg-01.alcatel-lucent.com [135.245.210.22]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1D8151B3791; Tue, 7 Apr 2015 09:16:01 -0700 (PDT)
Received: from fr711usmtp1.zeu.alcatel-lucent.com (unknown [135.239.2.122]) by Websense Email Security Gateway with ESMTPS id 95CA5216065D1; Tue, 7 Apr 2015 16:15:56 +0000 (GMT)
Received: from FR711WXCHHUB02.zeu.alcatel-lucent.com (fr711wxchhub02.zeu.alcatel-lucent.com [135.239.2.112]) by fr711usmtp1.zeu.alcatel-lucent.com (GMO) with ESMTP id t37GFuSI010407 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 7 Apr 2015 18:15:56 +0200
Received: from FR712WXCHMBA11.zeu.alcatel-lucent.com ([169.254.7.230]) by FR711WXCHHUB02.zeu.alcatel-lucent.com ([135.239.2.112]) with mapi id 14.03.0195.001; Tue, 7 Apr 2015 18:15:56 +0200
From: "DRAGE, Keith (Keith)" <keith.drage@alcatel-lucent.com>
To: Derek Atkins <derek@ihtfp.com>, "Timothy B. Terriberry" <tterribe@xiph.org>
Thread-Topic: [payload] [secdir] sec-dir review of draft-ietf-payload-rtp-opus-08
Thread-Index: AQHQcIQN7a+fOctgPDsHC1O01O6N4p1BtiGg
Date: Tue, 7 Apr 2015 16:15:55 +0000
Message-ID: <949EF20990823C4C85C18D59AA11AD8B4A124E8A@FR712WXCHMBA11.zeu.alcatel-lucent.com>
References: <sjmoaosz53h.fsf@securerf.ihtfp.org> <54E3A32F.2010008@jmvalin.ca> <760B7D45D1EFF74988DBF5C2122830C24D064CDE@szxpml507-mbx.exmail.huawei.com> <sjmk2zdzv6g.fsf@securerf.ihtfp.org> <916F29B3-E392-481B-A269-FBA58DFEF14D@nostrum.com> <551C612B.4030702@mozilla.com> <C3DD8EE5-B066-4C06-99F4-B9147A128811@nostrum.com> <C17AE3D5-F62D-42A3-9F1F-885BF1B984EB@nostrum.com> <551EFB9C.4040504@xiph.org> <sjmy4m5grwp.fsf@securerf.ihtfp.org>
In-Reply-To: <sjmy4m5grwp.fsf@securerf.ihtfp.org>
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [135.239.27.41]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: <http://mailarchive.ietf.org/arch/msg/secdir/2G2KzCL8p-vZ0QAWxiWBAHt3BwI>
Cc: "secdir@ietf.org" <secdir@ietf.org>, "payload@ietf.org" <payload@ietf.org>, "jspittka@gmail.com" <jspittka@gmail.com>, "iesg@ietf.org" <iesg@ietf.org>, "payload-chairs@tools.ietf.org" <payload-chairs@tools.ietf.org>, "koenvos74@gmail.com" <koenvos74@gmail.com>
Subject: Re: [secdir] [payload] sec-dir review of draft-ietf-payload-rtp-opus-08
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: Tue, 07 Apr 2015 16:16:06 -0000

You seem to be arguing that there are no security requirements specific for this codec.

I would suggest that the consequence of that is that we do not need RFC 2119 language in this document, and that Ben's language is actually more appropriate. RFC 2119 language should only be used in this area if there is a specific requirement for the codec.

If someone wants to introduce a SHOULD level strength requirement as a result on the perpass discussion, then that should be a separate generic document that updates the document that defines the concept of payload type definitions in the first place (is that currently RFC 4855?).

RFC 7202 is only an informative document and does not contain any requirements in this respect, merely giving guidance.

So if someone wants a normative statement in this respect, assuming one can be written that is actually specific enough to test, then a new document is required, probably from AVTCORE.

Keith

> -----Original Message-----
> From: payload [mailto:payload-bounces@ietf.org] On Behalf Of 
> Derek Atkins
> Sent: 06 April 2015 17:09
> To: Timothy B. Terriberry
> Cc: secdir@ietf.org; payload@ietf.org; jspittka@gmail.com; 
> iesg@ietf.org; payload-chairs@tools.ietf.org; 
> koenvos74@gmail.com; Derek Atkins
> Subject: Re: [payload] [secdir] sec-dir review of 
> draft-ietf-payload-rtp-opus-08
> 
> "Timothy B. Terriberry" <tterribe@xiph.org> writes:
> 
> > Ben Campbell wrote:
> >>> So my suggestion would be something more to the effect of:
> >>>
> >>> "Opus does not provide any built-in confidentiality or integrity 
> >>> protection. Protection requirements vary between RTP applications.
> >>> See RFC 7201 and RFC 7202 for a discussion.
> >
> > This seems like reasonable text to me. I agree with the 
> rationale that 
> > preceded it. As much as I want to see encryption 
> everywhere, a payload 
> > format is not the right place to mandate it.
> 
> As was stated already in this thread, the expected follow up 
> drafts for MTI security have not been written.
> 
> I leave it up to the Security ADs who have the real power 
> here, but I still prefer my original wording (including the SHOULD).
> 
> I understand your reluctance because it's a codec, but it's 
> the first codec to get through the process since the Perpass 
> work, which basically says "everything should be encrypted."  
> Since you cannot go back in time to modify the existing RFCs, 
> you can augment them going forward by other additions.
> 
> As for the concern about "different security requirements for 
> different codecs", frankly I don't buy that argument.  Either 
> your RTP application supports security or it doesn't.  Once 
> it does, it should be able to negotiate that along side the 
> codec negotitation.  So I don't see the concern -- we're not 
> mandating a specific security technology, just that you 
> SHOULD use one.  Well, that's true regardless of the codec, isn't it?
> 
> Or are you really saying "We don't care about security.  We 
> just want to be able to use this codec in existing, insecure 
> RTP applications without adding new securty measures"?
> 
> -derek
> -- 
>        Derek Atkins                 617-623-3745
>        derek@ihtfp.com             www.ihtfp.com
>        Computer and Internet Security Consultant
> 
> _______________________________________________
> payload mailing list
> payload@ietf.org
> https://www.ietf.org/mailman/listinfo/payload
>