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

Colin Perkins <csp@csperkins.org> Tue, 07 April 2015 16:23 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 B54D41A8A50; Tue, 7 Apr 2015 09:23:55 -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 2e2ox7vLhcr4; Tue, 7 Apr 2015 09:23:53 -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 BF9621A8A51; Tue, 7 Apr 2015 09:23:53 -0700 (PDT)
Received: from [130.209.247.112] (port=53060 helo=mangole.dcs.gla.ac.uk) by haggis.mythic-beasts.com with esmtpsa (TLS1.0:RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from <csp@csperkins.org>) id 1YfWI1-0003ca-C4; Tue, 07 Apr 2015 17:23:50 +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: <5523FEEB.60000@cs.tcd.ie>
Date: Tue, 7 Apr 2015 17:23:33 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <DBBCEE5E-3B85-47BB-9FF8-DB84D7549203@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> <5523FEEB.60000@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/QIfdBG1Kb5zYbS0GKAuXZ1dvoPg>
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>, 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: Tue, 07 Apr 2015 16:23:55 -0000

On 7 Apr 2015, at 16:59, Stephen Farrell <stephen.farrell@cs.tcd.ie> wrote:
> Hiya,
> 
> Sorry for coming late to this thread (#include <itwasaweekend.h> :-)
> 
> On 06/04/15 19:44, Robert Sparks wrote:
> [...]
>>> 
>>> 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.
> 
> Robert is correct.
> 
>> 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.
> 
> I do recall that now that you mention it. But if it's not actually
> going to happen, then maybe we should rethink the approach, even if
> that'd result in repeated text in payload format drafts.
> 
> Who knows the status of that work?

I don't know the status of that work, but irrespective of that, payload format documents are not the right place to mandate security for RTP. 

An RTP payload format is a media type registration. RTP is a transport protocol. Transport security should be defined for the transport, not for the media type being transported, since there are different ways of transporting the media that can have different security properties. This is the argument of RFC 7202. 

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