[AVTCORE] Comments on draft-ietf-avt-srtp-not-mandatory-09

"Brandenburg, R. (Ray) van" <ray.vanbrandenburg@tno.nl> Fri, 03 August 2012 02:23 UTC

Return-Path: <ray.vanbrandenburg@tno.nl>
X-Original-To: avt@ietfa.amsl.com
Delivered-To: avt@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 748B211E80A4 for <avt@ietfa.amsl.com>; Thu, 2 Aug 2012 19:23:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.238
X-Spam-Level:
X-Spam-Status: No, score=0.238 tagged_above=-999 required=5 tests=[AWL=0.741, BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v0plhekrldkO for <avt@ietfa.amsl.com>; Thu, 2 Aug 2012 19:22:59 -0700 (PDT)
Received: from fromintoutb.tno.nl (fromintoutb.tno.nl [134.221.1.27]) by ietfa.amsl.com (Postfix) with ESMTP id F2EC221F8510 for <avt@ietf.org>; Thu, 2 Aug 2012 19:22:58 -0700 (PDT)
X-IronPort-AV: E=Sophos; i="4.77,704,1336341600"; d="scan'208,217"; a="15928396"
Received: from unknown (HELO mail.tno.nl) ([134.221.225.220]) by mailhost1b.tno.nl with ESMTP; 03 Aug 2012 04:22:53 +0200
Received: from EXC-MBX03.tsn.tno.nl ([169.254.3.96]) by EXC-CASHUB01.tsn.tno.nl ([134.221.225.220]) with mapi id 14.02.0298.004; Fri, 3 Aug 2012 04:22:53 +0200
From: "Brandenburg, R. (Ray) van" <ray.vanbrandenburg@tno.nl>
To: "avt@ietf.org" <avt@ietf.org>, Magnus Westerlund <magnus.westerlund@ericsson.com>, "csp@csperkins.org" <csp@csperkins.org>
Thread-Topic: Comments on draft-ietf-avt-srtp-not-mandatory-09
Thread-Index: AQHNcQ90k9ZpJzgdtEut8HGzsNKSdJdHW6aN
Date: Fri, 3 Aug 2012 02:22:52 +0000
Message-ID: <FD4DC1EE-F3B9-46C9-ABD3-CAA59AB45EDB@tno.nl>
References: <CAEWORyfY+xZ-8LFnezmjcpjtg2ixCdNen5x0ZgPaRRF8XyzLnQ@mail.gmail.com>
In-Reply-To: <CAEWORyfY+xZ-8LFnezmjcpjtg2ixCdNen5x0ZgPaRRF8XyzLnQ@mail.gmail.com>
Accept-Language: en-US, nl-NL
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Content-Type: multipart/alternative; boundary="_000_FD4DC1EEF3B946C9ABD3CAA59AB45EDBtnonl_"
MIME-Version: 1.0
Subject: [AVTCORE] Comments on draft-ietf-avt-srtp-not-mandatory-09
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.1.12
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: Fri, 03 Aug 2012 02:23:00 -0000

Hi Colin/Magnus,


This is my review of draft-ietf-avt-srtp-not-mandatory-09. Since I'm not a security expert, I can't say anything about the security implications of the document. That said, I do have some other comments. I've not been following the discussion on this topic very closely on the list, so please excuse me if any topics I bring up have already been discussed on list earlier.


1) The page-header of the draft is 'SRTP is not the only RTP Security Option'. Although I understand that this header summarizes the rationale for writing the draft in the first place, from reading the abstract and introduction of the draft, this header seems a little out of place. I would suggest to either more clearly describe its relevance in the abstract or introduction (where SRTP is not mentioned), or choose a different header.


2) Section 3, paragraph 3 states that SRTP is not suitable for some scenarios and applications. I completely agree with this, but the text could use at least one example of such an application or scenario, and reasons for SRTP not being applicable to that application, especially since it is fundamental to the argument being made in the draft (that there is no individual RTP security methods which is suitable for all applications). Basically, the draft spends a lot of time explaining why RTP is a framework and it is therefore not possible to mandate any single security mechanism, however, it doesn't explain why the most-used security mechanism (SRTP) is not suitable for this.


3) Section 6 describes the actual guidelines for future security extensions for RTP that are mentioned in the abstract, and in that sense forms a important part of the draft. It might be useful to more clearly indicate/highlight them in that way (e.g. by changing the section title to include the word 'guidelines').


4) The conclusion (section 7) states 'it is hoped that this memo explains why SRTP is not mandatory as the media security solution for RTP-based systems'. This conclusion could be supported by more substantial arguments in the rest of the document, especially related to SRTP, which is not mentioned apart from the brief mention in section 3, where no actual arguments are given. See also comment 2).


5) And some nits:

- Section 7: comon -> common

- Section 7: important consider -> important to consider

- Section 7: applications -> application


Best regards,


Ray
This e-mail and its contents are subject to the DISCLAIMER at http://www.tno.nl/emaildisclaimer