Re: [AVTCORE] Last Call: <draft-ietf-avt-srtp-not-mandatory-14.txt> (Securing the RTP Protocol Framework: Why RTP Does Not Mandate a Single Media Security Solution) to Informational RFC

Colin Perkins <csp@csperkins.org> Tue, 10 December 2013 06:53 UTC

Return-Path: <csp@csperkins.org>
X-Original-To: avt@ietfa.amsl.com
Delivered-To: avt@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE69A1AE04D; Mon, 9 Dec 2013 22:53:17 -0800 (PST)
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 V6hu2XDvBBYH; Mon, 9 Dec 2013 22:53:16 -0800 (PST)
Received: from balrog.mythic-beasts.com (balrog.mythic-beasts.com [IPv6:2a00:1098:0:82:1000:0:2:1]) by ietfa.amsl.com (Postfix) with ESMTP id 070781AD8D8; Mon, 9 Dec 2013 22:53:16 -0800 (PST)
Received: from [87.213.41.162] (port=62661 helo=[10.71.0.165]) by balrog.mythic-beasts.com with esmtpsa (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.72) (envelope-from <csp@csperkins.org>) id 1VqHBt-0003vy-7q; Tue, 10 Dec 2013 06:53:09 +0000
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\))
From: Colin Perkins <csp@csperkins.org>
In-Reply-To: <5B0CCCC0-9E65-467B-A9C8-799CBBB85AA6@cisco.com>
Date: Tue, 10 Dec 2013 07:53:08 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <A7AB59BA-3DE4-4F0A-8745-087D2D9DF93E@csperkins.org>
References: <20131122220752.31098.83432.idtracker@ietfa.amsl.com> <1286562B-6C43-4ADC-8999-C70CA356F587@cisco.com> <89E376B0-5555-40D8-A59E-0286CABC856C@csperkins.org> <BC503965-42C2-4E02-B7C2-70550EBB11C1@cisco.com> <0FA6EC2C-3FAB-4E72-882E-13640108C328@csperkins.org> <5B0CCCC0-9E65-467B-A9C8-799CBBB85AA6@cisco.com>
To: Cullen Jennings (fluffy) <fluffy@cisco.com>
X-Mailer: Apple Mail (2.1510)
X-BlackCat-Spam-Score: -28
X-Mythic-Debug: Threshold = On =
Cc: "ietf@ietf.org" <ietf@ietf.org>, "avt@ietf.org WG" <avt@ietf.org>
Subject: Re: [AVTCORE] Last Call: <draft-ietf-avt-srtp-not-mandatory-14.txt> (Securing the RTP Protocol Framework: Why RTP Does Not Mandate a Single Media Security Solution) to Informational RFC
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Audio/Video Transport Core Maintenance <avt.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/avt>, <mailto:avt-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/avt/>
List-Post: <mailto:avt@ietf.org>
List-Help: <mailto:avt-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/avt>, <mailto:avt-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 10 Dec 2013 06:53:18 -0000

On 10 Dec 2013, at 00:55, Cullen Jennings (fluffy) <fluffy@cisco.com> wrote:
> WebRTC is a framework. HTTP is a framework. SIP is a framework. All of these can be used in very different ways with different deployments.

So is RTP. That is the point of writing this draft.

> I don't see RTP being a somehow special relative to many other protocols the IETF develops from the point of view of not having a minimal interoperable way of securing it. 

What would that be? SRTP does not make sense for many deployments, and even if it did, doesn't address keying.

> So lets be blunt here - this document is about justifying that RTP will not have any MTI security.

Absolutely not. It's about saying that the appropriate MTI security depends on the class of applications. What makes sense for telephony doesn't necessarily make sense for IPTV, etc.

> I will note that rtp-security-options also does not add any MTI security requirements to RTP.  

No, but it references documents that describe the MTI security for some particular scenarios where RTP is used (e.g., the WebRTC security arch). 

> I'm OK with that. All I am raising is that was  that I don't believe that has IETF consensus based on the question at the last plenary.  If you think it does, now would be a great time to outline that argument. 

I believe there is IETF consensus that RTP needs strong security. This draft discusses how to achieve that.

> Lets just keep in perspective here that what we are talking about is the protocol use for transporting people voice when the PSTN is replaced in the US and the position of this RFC, and presumable the IETF if it is published, is that the IETF is not going to mandate a way to secure this. 

That's kind-of the point: RTP is not *just* the protocol that transports voice when the PSTN is replaced; it's used in a myriad of other scenarios that are outlined in the draft. If RTP were just used for telephony, this problem would be straight-forward, and we'd have a draft specifying MTI security. As RTP is used much more widely, the requirements are more complex. This draft outlines some of the issues, it doesn't claim to provide the solution to RTP security.

Again, if there is specific text in the draft that makes this unclear, let us know and we will fix this.

Colin