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

Colin Perkins <csp@csperkins.org> Thu, 09 April 2015 10:11 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 222BF1B2DC3; Thu, 9 Apr 2015 03:11:25 -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 RIn5TJCF2eJ8; Thu, 9 Apr 2015 03:11:23 -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 79A281B2DC1; Thu, 9 Apr 2015 03:11:23 -0700 (PDT)
Received: from [81.187.2.149] (port=39994 helo=[192.168.0.18]) by balrog.mythic-beasts.com with esmtpsa (TLS1.0:RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from <csp@csperkins.org>) id 1Yg9Qf-00089G-59; Thu, 09 Apr 2015 11:11:21 +0100
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
From: Colin Perkins <csp@csperkins.org>
In-Reply-To: <55264EAB.6090804@cs.tcd.ie>
Date: Thu, 09 Apr 2015 11:11:08 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <5D09A2DB-8A85-43ED-9EEC-C5CC2867F68A@csperkins.org>
References: <sjmoaosz53h.fsf@securerf.ihtfp.org> <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> <B9A87595-5AAF-47CA-B898-8C8601D3B8C1@nostrum.com> <f9665835930b18598 ce87f90b8296b39.squirrel@mail2.ihtfp.org> <8D455380-E490-4026-8485-4CE05F345E7F@nostrum.com> <82197574-D574-45C1-BFCF-0826E0037ED3@csperkins.org> <55264EAB.609080 4@cs.tcd.ie>
To: Stephen Farrell <stephen.farrell@cs.tcd.ie>
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/wXanz9V58cr1KuWcZogBo4vikUc>
Cc: Ben Campbell <ben@nostrum.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
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: Thu, 09 Apr 2015 10:11:25 -0000

On 9 Apr 2015, at 11:04, Stephen Farrell <stephen.farrell@cs.tcd.ie> wrote:
> I do agree with Colin here (and with Ben and Robert) but...
> 
> On 09/04/15 10:58, Colin Perkins wrote:
>> A document giving normative security guidance for unicast SIP-based
>> telephony using RTP is something we need, I agree. I'm happy to help
>> reviewing such a thing, but it should be authored by someone more
>> familiar with the deployed security mechanisms.
> 
> I've just gotten offlist mail from another secdir reviewer who
> noted that we had exactly the same discussion 7 years ago for
> another payload document. And I recall it myself more recently.

We've been around this loop multiple times. That's why we wrote RFCs 7201 and 7202, to try to stop repeating the same discussion by explaining the issues and providing guidance. The recommended text for new RTP payload formats in the rtp-howto was also intended to help clarify. Clearly something more is needed. If the issue is that RFC7202 isn't clear, then I'm happy to work with someone to clarify in an update, but I suspect we need the suggested documents giving normative requirements for different application classes.

> So that unicast SIP/RTP document really would save us all some
> time and might help those implementing and deploying security
> stuff in such cases. (And even if folks were not implementing
> or deploying security stuff for this 7 years ago, I would say
> that it's much more likely they will be doing that today and
> in future.)

Agreed.

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