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

Colin Perkins <csp@csperkins.org> Wed, 08 April 2015 16:01 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 519BC1B332E; Wed, 8 Apr 2015 09:01:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 Iy-B_icQeT6D; Wed, 8 Apr 2015 09:01:18 -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 67A6B1B333F; Wed, 8 Apr 2015 08:59:21 -0700 (PDT)
Received: from [130.209.247.112] (port=62464 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 1YfsNq-0006cd-IS; Wed, 08 Apr 2015 16:59:18 +0100
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
Content-Type: text/plain; charset=us-ascii
From: Colin Perkins <csp@csperkins.org>
X-Priority: 3 (Normal)
In-Reply-To: <759691e866a2fc8c41aa43acc18cbd19.squirrel@mail2.ihtfp.org>
Date: Wed, 8 Apr 2015 16:59:12 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <C829D32E-7E03-496C-AB33-FE8C10247F3B@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> <927CC992-13D7-41B9-A9AF-7F4E31905DF2@csperkins.org> <sjmd23ehf4o.fsf@securerf.ihtfp.org> <402C1C17-65A1-4461-9CA8-D7035022DEFE@csperkins.org> <759691e866a2fc8c41aa43acc18cbd19.squirrel@mail2.ihtfp.org>
To: Derek Atkins <derek@ihtfp.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/k1oB2NzVqrvPeUhzE_UhNHwLx9E>
Cc: Roni Even <ron.even.tlv@gmail.com>, Magnus Westerlund <magnus.westerlund@ericsson.com>, Jean-Marc Valin <jmvalin@mozilla.com>, "secdir@ietf.org" <secdir@ietf.org>, payload@ietf.org, jspittka@gmail.com, Kathleen Moriarty <kathleen.moriarty.ietf@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 16:01:20 -0000

On 8 Apr 2015, at 15:42, Derek Atkins <derek@ihtfp.com> wrote:
> On Wed, April 8, 2015 10:35 am, Colin Perkins wrote:
> [snip]
>> 
>> And as I keep saying, I believe that is inappropriate, since it's
>> recommending SRTP which is not suitable for many applications. The
>> rtp-howto draft suggests the following text:
>> 
> [sniped and added below]
>> 
>> (The two drafts referenced are what became RFCs 7201 and 7202).
>> 
>> If you want to augment that with a "strong security SHOULD/MUST be used",
>> then I certainly don't object. However, a payload format really shouldn't
>> be trying to recommend use of a particular RTP security solution, such as
>> SRTP.
> 
> Okay, so if you want to change the text completely (which I'm fine with),
> how about just adding a single sentence to the end of what you have:
> 
>   RTP packets using the payload format defined in this specification
>   are subject to the security considerations discussed in the RTP
>   specification RFC3550, and in any applicable RTP profile such as
>   RTP/AVP [RFC3551], RTP/AVPF [RFC4585], RTP/SAVP [RFC3711] or RTP/
>   SAVPF [RFC5124].  However, as "Securing the RTP Protocol Framework:
>   Why RTP Does Not Mandate a Single Media Security Solution"
>   [I-D.ietf-avt-srtp-not-mandatory] discusses it is not an RTP payload
>   formats responsibility to discuss or mandate what solutions are used
>   to meet the basic security goals like confidentiality, integrity and
>   source authenticity for RTP in general.  This responsibility lays on
>   anyone using RTP in an application.  They can find guidance on
>   available security mechanisms and important considerations in Options
>   for Securing RTP Sessions [I-D.ietf-avtcore-rtp-security-options].
>   Applications SHOULD implement at least one of the strong security
>   measures suggested by those references.

Sure, that's fine (Magnus might want to update the rtp-howto with that extra text too).

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