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

Colin Perkins <csp@csperkins.org> Thu, 09 April 2015 09:58 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 B6D6E1B2D6B; Thu, 9 Apr 2015 02:58:40 -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 JJOzNCKcwYwE; Thu, 9 Apr 2015 02:58:38 -0700 (PDT)
Received: from haggis.mythic-beasts.com (haggis.mythic-beasts.com [IPv6:2a00:1098:0:86: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 A67411AD0AA; Thu, 9 Apr 2015 02:58:38 -0700 (PDT)
Received: from [81.187.2.149] (port=33612 helo=[192.168.0.18]) by haggis.mythic-beasts.com with esmtpsa (TLS1.0:RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from <csp@csperkins.org>) id 1Yg9EG-0001bd-UM; Thu, 09 Apr 2015 10:58:35 +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: <8D455380-E490-4026-8485-4CE05F345E7F@nostrum.com>
Date: Thu, 9 Apr 2015 10:58:17 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <82197574-D574-45C1-BFCF-0826E0037ED3@csperkins.org>
References: <sjmoaosz53h.fsf@securerf.ihtfp.org> <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> <B9A87595-5AAF-47CA-B898-8C8601D3B8C1@nostrum.com> <f9665835930b18598 ce87f90b8296b39.squirrel@mail2.ihtfp.org> <8D455380-E490-4026-8485-4CE05F345E7F@nostrum.com>
To: Ben Campbell <ben@nostrum.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/1jvUWRj7to6_PeB19lZENnOuJz4>
Cc: "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 09:58:40 -0000

On 8 Apr 2015, at 20:49, Ben Campbell <ben@nostrum.com> wrote:
> On 8 Apr 2015, at 14:38, Derek Atkins wrote:
>> 
>> On Wed, April 8, 2015 2:52 pm, Ben Campbell wrote:
>>> On 8 Apr 2015, at 9:42, Derek Atkins wrote:
...snip...
>>> For an extreme example, having that sentence in Codec format A and not
>>> format B could lead to implementor decisions on the order of "I don't
>>> want to bother with crypto, so I will choose codec B because it has
>>> lighter requirements" might appear to make sense to someone not steeped
>>> in this argument.
>>> 
>>> What I'd _really_ like to do is take the energy in this thread and apply
>>> it to creating a standards-track security document for RTP unicast
>>> applications.
>> 
>> Are you willing to hold up this document until that work is done so it can
>> refer to the (yet-to-be-written) protocol security update draft?  I'm fine
>> with that approach and I'm willing to review whatever draft you guys
>> produce if that's how you'd like to proceed.
> 
> No, I will go with the consensus on this one. I note that several WG participants objected to the orignally proposed SHOULD. I am pointing out that this SHOULD is not much different, but I will go with what people want to do.

I think "SHOULD use an appropriate strong security mechanism" is quite different to "SHOULD use SRTP", since we know of cases where SRTP isn't suitable. That was my objection to the original text.

> OTOH, what I would like to do would fix the problem for this, and all other codec payload formats, after the fact if we do it right (since it would apply to the application)
> 
>> 
>> Or you can hold your nose and live with the "UGGH" of it based on what the
>> WG original created in -08 and move forward for now, knowing that you can
>> (and should) correct it "right" later.
> 
> The work group did not put in a SHOULD. I think this is more of a question of whether people are willing to hold there collective noses about the lack of _normative_ privacy guidance for RTP in general, and if they are willing to let payload formats continue to progress while that is being worked out.

One of the things RFC 7202 tries to convey is that "normative privacy guidance for RTP in general" is not possible. The privacy requirements, for example, of broadcast TV are different to those for a phone call, but both can use RTP. 

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.


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