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

"Scott G. Kelly" <scott@hyperthought.com> Thu, 04 November 2010 16:31 UTC

Return-Path: <scott@hyperthought.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 DBF203A69DC for <secdir@core3.amsl.com>; Thu, 4 Nov 2010 09:31:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.061
X-Spam-Level:
X-Spam-Status: No, score=-4.061 tagged_above=-999 required=5 tests=[AWL=-0.462, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
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 r-6OK04xXgwY for <secdir@core3.amsl.com>; Thu, 4 Nov 2010 09:31:22 -0700 (PDT)
Received: from smtp132.iad.emailsrvr.com (smtp132.iad.emailsrvr.com [207.97.245.132]) by core3.amsl.com (Postfix) with ESMTP id 9FF633A6927 for <secdir@ietf.org>; Thu, 4 Nov 2010 09:31:22 -0700 (PDT)
Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp43.relay.iad1a.emailsrvr.com (SMTP Server) with ESMTP id B20F22D0803; Thu, 4 Nov 2010 12:31:32 -0400 (EDT)
X-Virus-Scanned: OK
Received: from dynamic4.wm-web.iad.mlsrvr.com (dynamic4.wm-web.iad1a.rsapps.net [192.168.2.153]) by smtp43.relay.iad1a.emailsrvr.com (SMTP Server) with ESMTP id 779382D07DD; Thu, 4 Nov 2010 12:31:32 -0400 (EDT)
Received: from hyperthought.com (localhost [127.0.0.1]) by dynamic4.wm-web.iad.mlsrvr.com (Postfix) with ESMTP id 567211D4A25F; Thu, 4 Nov 2010 12:31:32 -0400 (EDT)
Received: by apps.rackspace.com (Authenticated sender: scott@hyperthought.com, from: scott@hyperthought.com) with HTTP; Thu, 4 Nov 2010 09:31:32 -0700 (PDT)
Date: Thu, 4 Nov 2010 09:31:32 -0700 (PDT)
From: "Scott G. Kelly" <scott@hyperthought.com>
To: "secdir@ietf.org" <secdir@ietf.org>, "iesg@ietf.org" <iesg@ietf.org>, draft-ietf-avt-rtp-h264-rcdo.all@tools.ietf.org
MIME-Version: 1.0
Content-Type: text/plain;charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Importance: Normal
X-Priority: 3 (Normal)
X-Type: plain
Message-ID: <1288888292.35265529@192.168.2.228>
X-Mailer: webmail8
Subject: [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: Thu, 04 Nov 2010 16:31:24 -0000

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 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).

--Scott