Re: [secdir] secdir review of draft-ietf-avt-rtp-h264-rcdo-07

Patrick Luthi <patrick.luthi@tandberg.com> Fri, 05 November 2010 18:29 UTC

Return-Path: <patrick.luthi@tandberg.com>
X-Original-To: secdir@core3.amsl.com
Delivered-To: secdir@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AB8CC3A691C; Fri, 5 Nov 2010 11:29:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.599
X-Spam-Level:
X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZEgeMcf-Nt56; Fri, 5 Nov 2010 11:29:47 -0700 (PDT)
Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id 3E11E3A6919; Fri, 5 Nov 2010 11:29:47 -0700 (PDT)
Authentication-Results: rtp-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Av0EAOHp00ytJV2a/2dsb2JhbACGRpsncaBjmz6FSASNZg
X-IronPort-AV: E=Sophos;i="4.58,304,1286150400"; d="scan'208";a="179040381"
Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rtp-iport-2.cisco.com with ESMTP; 05 Nov 2010 18:29:59 +0000
Received: from OSLEXCP11.eu.tandberg.int ([173.38.136.5]) by rcdn-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id oA5ITwJk030849; Fri, 5 Nov 2010 18:29:58 GMT
Received: from oslexcp2.eu.tandberg.int ([10.47.136.30]) by OSLEXCP11.eu.tandberg.int with Microsoft SMTPSVC(6.0.3790.3959); Fri, 5 Nov 2010 19:29:58 +0100
Received: from Suisse129.tandberg.com ([128.107.141.242]) by oslexcp2.eu.tandberg.int with Microsoft SMTPSVC(6.0.3790.3959); Fri, 5 Nov 2010 19:29:56 +0100
X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9
Date: Fri, 05 Nov 2010 19:23:43 +0100
To: Tom Kristensen <tom.kristensen@tandberg.com>, "Scott G. Kelly" <scott@hyperthought.com>
From: Patrick Luthi <patrick.luthi@tandberg.com>
In-Reply-To: <4CD3FCA4.70401@tandberg.com>
References: <1288888292.35265529@192.168.2.228> <4CD3FCA4.70401@tandberg.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Message-ID: <OSLEXCP2XvpFVjCRGry00000012@oslexcp2.eu.tandberg.int>
X-OriginalArrivalTime: 05 Nov 2010 18:29:56.0953 (UTC) FILETIME=[72899490:01CB7D17]
X-Mailman-Approved-At: Sat, 06 Nov 2010 17:57:25 -0700
Cc: "iesg@ietf.org" <iesg@ietf.org>, draft-ietf-avt-rtp-h264-rcdo.all@tools.ietf.org, "secdir@ietf.org" <secdir@ietf.org>
Subject: Re: [secdir] secdir review of draft-ietf-avt-rtp-h264-rcdo-07
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/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: Fri, 05 Nov 2010 18:29:48 -0000

Tom,

Your proposed text sounds good to me!

Regards,

Patrick

At 13:46 05/11/2010, Tom Kristensen wrote:
>On 11/04/2010 05:31 PM, Scott G. Kelly wrote:
>>I have reviewed this document as part of the security directorate's 
>>ongoing effort to review all IETF documents being processed by the 
>>IESG.  These comments were written primarily for the benefit of the 
>>security area directors.  Document editors and WG chairs should 
>>treat these comments just like any other last call comments.
>>
>>This draft describes a new RTP payload format, extending existing 
>>RTP capabilities. Based on my limited understanding of RTP, this 
>>introduces no new security considerations.
>>
>>The security considerations section starts off by saying this, but 
>>then goes on to talk about various security properties that could 
>>be added by various means. I found the text to be a little 
>>confusing, especially when it makes recommendations without 
>>detailing any particular threats.
>
>I can understand this conclusion. A simplification makes sense as 
>the recommendations given here is described better within a security 
>context in the RTP RFC and associated specifications. However, I'd 
>like to keep the reference to the H.264 security considerations, 
>with its codec specific details. My proposed text for the security 
>considerations at bottom.
>
>>I would suggest simplifying the security considerations. Here is 
>>the current text:
>>
>>    "RTP packets using the payload format defined in this specification
>>     are subject to the security considerations discussed in the RTP
>>     specification [6], and in any applicable RTP profile.  The main
>>     security considerations for the RTP packet carrying the RTP payload
>>     format defined within this document are confidentiality, integrity
>>     and source authenticity.  Confidentiality is achieved by encryption
>>     of the RTP payload.  Integrity of the RTP packets through suitable
>>     cryptographic integrity protection mechanism.  Cryptographic system
>>     may also allow the authentication of the source of the payload.  A
>>     suitable security mechanism for this RTP payload format should
>>     provide confidentiality, integrity protection and at least source
>>     authentication capable of determining if an RTP packet is from a
>>     member of the RTP session or not.
>>
>>     Note that the appropriate mechanism to provide security to RTP and
>>     payloads following this document may vary.  It is dependent on the
>>     application, the transport, and the signalling protocol employed.
>>     Therefore a single mechanism is not sufficient.  Usage of data origin
>>     authentication and data integrity protection of at least the RTP
>>     packet is RECOMMENDED, for example by use of the Secure Real-time
>>     Transport Protocol (SRTP) [12].  Other mechanisms that may be used
>>     are IPsec [13] and Transport Layer Security (TLS) [14] (RTP over
>>     TCP), but other alternatives may exist.
>>
>>     Refer also to section 9 of RFC YYYY [3], as no reasons for separate
>>     considerations are introduced in this document."
>>
>>
>>I would suggest the following simplified text:
>>
>>    "RTP packets using the payload format defined in this specification
>>     are subject to the security considerations discussed in the RTP
>>     specification [6], and in any applicable RTP profile.  No additional
>>     security considerations are introduced by this specification."
>>
>>(or something like this).
>
>I would like to keep the reference to the security considerations 
>section of RFC YYYY/RFC3984bis in, as specific H.264 threats and 
>recommendations are included there. Cf.:
>http://tools.ietf.org/html/draft-ietf-avt-rtp-rfc3984bis-12#section-9
>
>So, something like this should be fine:
>
>   "RTP packets using the payload format defined in this specification
>    are subject to the security considerations discussed in the RTP
>    specification [6], and in any applicable RTP profile. Refer also
>    to section 9 of RFC YYYY [3]. No additional security
>    considerations are introduced by this specification."
>
>As a side note. One might consider altering the "template security 
>considerations" section in the "How to Write an RTP Payload Format" 
>draft according to the preferred security directorate/IESG policy 
>for the RTP payload format specifications later on. Cf.:
>http://tools.ietf.org/html/draft-ietf-avt-rtp-howto-06#appendix-A.13
>
>-- Tom