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

Colin Perkins <csp@csperkins.org> Mon, 06 April 2015 18:51 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 0EE771A90CA; Mon, 6 Apr 2015 11:51:01 -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 fdMZKNhWXqe7; Mon, 6 Apr 2015 11:50:56 -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 96A131A90C7; Mon, 6 Apr 2015 11:50:56 -0700 (PDT)
Received: from [81.187.2.149] (port=39688 helo=[192.168.0.22]) by balrog.mythic-beasts.com with esmtpsa (TLS1.0:RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from <csp@csperkins.org>) id 1YfC6i-0001si-D2; Mon, 06 Apr 2015 19:50:52 +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: <5522D40E.8040402@nostrum.com>
Date: Mon, 06 Apr 2015 19:50:23 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <73626E80-1EBA-4A85-83DD-32423649DBD1@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>
To: Robert Sparks <rjsparks@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/UAmVT2eEVWnNn3jyLxCCFNM248Q>
Cc: Ben Campbell <ben@nostrum.com>, "secdir@ietf.org" <secdir@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: Mon, 06 Apr 2015 18:51:01 -0000

On 6 Apr 2015, at 19:44, Robert Sparks <rjsparks@nostrum.com> wrote:
> inline (particularly for Derek)
> On 4/6/15 11:13 AM, Ben Campbell wrote:
>> On 6 Apr 2015, at 11:09, Derek Atkins wrote:
>> 
>>> "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"?
>> 
>> I'm saying this is the wrong layer to solve the problem.
>> 
>> We had some work planned to better specify this in general for RTP. I think the right answer is finish that work. If we do that right, it should apply regardless of codec.
>> 
> That's exactly right.
> 
> We've had this conversation several times before. The individual payload documents are not the place to add the kind of guidance Derek is asking for. They should be about how you put things in RTP, not how applications use (and secure RTP), unless there's something unique about the payload that interacts with the general mechanics for using and securing RTP.
> 
> Stephen will remember that we've queued up work on a document that would describe securing unicast RTP set up with SDP (capturing the outcome of the rtpsec bof at IETF68). The last I heard on the subject Dan Wing was taking the token to work on that document, but it's been awhile. That's where the effort should focus - an individual payload document is not the right place.

+1 

As Robert, and others, say, RTP payload format documents are not the right place to mandate security mechanisms. This is the point of RFC7202, which is about how strong security can best be defined for classes of RTP applications. This is not in conflict with the perpass work, since the goal of RFC7202 is to show how to provide strong security.

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