IETF Logo Mail Archive

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

Colin Perkins <csp@csperkins.org> Wed, 08 April 2015 09:08 UTC

Return-Path: <csp@csperkins.org>
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 3356E1A1A7B; Wed, 8 Apr 2015 02:08:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001] 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 ojpD6LajkMeX; Wed, 8 Apr 2015 02:08:31 -0700 (PDT)
Received: from balrog.mythic-beasts.com (balrog.mythic-beasts.com [IPv6:2a00:1098:0:82:1000:0:2:1]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E6B3F1A0078; Wed, 8 Apr 2015 02:08:30 -0700 (PDT)
Received: from [130.209.247.112] (port=58266 helo=mangole.dcs.gla.ac.uk) by balrog.mythic-beasts.com with esmtpsa (TLS1.0:RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from <csp@csperkins.org>) id 1YflyG-00035Y-Bt; Wed, 08 Apr 2015 10:08:28 +0100
Content-Type: multipart/alternative; boundary="Apple-Mail=_38F10A7C-6333-4A3E-881D-A1158D3B11CA"
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
From: Colin Perkins <csp@csperkins.org>
In-Reply-To: <CAHbuEH63BtaENfm6-_itp1eLtSCyC8LRvGbGPbKVAR-k6GQdZA@mail.gmail.com>
Date: Wed, 08 Apr 2015 10:08:14 +0100
Message-Id: <927CC992-13D7-41B9-A9AF-7F4E31905DF2@csperkins.org>
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> <269A06E2-6704-4E5E-BBFD-92F157639261@nostrum.com> <5522D40E.8040402@nostrum.com> <73626E80-1EBA-4A85-83DD-32423649DBD1@csperkins.org> <035501d0711a$7856b0a0$690411e0$@gmail.com> <5523C5AE.7040108@mozilla.com> <sjmpp7ggft8.fsf@securerf.ihtfp.org> <CAHbuEH63BtaENfm6-_itp1eLtSCyC8LRvGbGPbKVAR-k6GQdZA@mail.gmail.com>
To: Kathleen Moriarty <kathleen.moriarty.ietf@gmail.com>
X-Mailer: Apple Mail (2.1878.6)
X-BlackCat-Spam-Score: -28
X-Mythic-Debug: Threshold = On =
Archived-At: <http://mailarchive.ietf.org/arch/msg/secdir/2Ws1MmO2DuWm17pcg0aXq9JT-zw>
Cc: Roni Even <ron.even.tlv@gmail.com>, Jean-Marc Valin <jmvalin@mozilla.com>, "secdir@ietf.org" <secdir@ietf.org>, payload@ietf.org, jspittka@gmail.com, "iesg@ietf.org" <iesg@ietf.org>, payload-chairs@tools.ietf.org, koenvos74@gmail.com, Robert Sparks <rjsparks@nostrum.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: Wed, 08 Apr 2015 09:08:33 -0000

On 8 Apr 2015, at 01:12, Kathleen Moriarty <kathleen.moriarty.ietf@gmail.com> wrote:
> On Tue, Apr 7, 2015 at 10:42 AM, Derek Atkins <derek@ihtfp.com> wrote:
> Hi,
> 
> Jean-Marc Valin <jmvalin@mozilla.com> writes:
> 
> > Does anyone object to this earlier proposal?
> >
> > "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."
> 
> I'm okay with this text and did read the subsequent messages in this thread.  Since there is a MAY already for session encryption, that's why we were inserting a SHOULD.  I'm fine with getting rid of the RFC2119 language, but having some generic advice about RTP payloads.  Since there is no draft ready or in the works to fix this problem where it should be fixed, I do think it's a good idea to address the concern here and going forward.  Once it's fixed int eh right place, then references and text changes going forward.

There is some guidance in draft-ietf-payload-rtp-howto-13 sections 7.2 and A.13 for payload format text. That draft is in the RFC Editor queue, but I'm sure Magnus would be pleased to receive feedback if the suggestions there are not clear.


-- 
Colin Perkins
https://csperkins.org/

v2.23.0 | Report a Bug | By Email