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

Colin Perkins <csp@csperkins.org> Mon, 22 October 2012 11:37 UTC

Return-Path: <csp@csperkins.org>
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 CBE4721F8BB6 for <avt@ietfa.amsl.com>; Mon, 22 Oct 2012 04:37:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -105.848
X-Spam-Level:
X-Spam-Status: No, score=-105.848 tagged_above=-999 required=5 tests=[AWL=0.750, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w1LTDe3T1qlm for <avt@ietfa.amsl.com>; Mon, 22 Oct 2012 04:37:44 -0700 (PDT)
Received: from balrog.mythic-beasts.com (balrog.mythic-beasts.com [93.93.130.6]) by ietfa.amsl.com (Postfix) with ESMTP id 7BC6521F8BB0 for <avt@ietf.org>; Mon, 22 Oct 2012 04:37:44 -0700 (PDT)
Received: from [130.209.247.112] (helo=mangole.dcs.gla.ac.uk) by balrog.mythic-beasts.com with esmtpsa (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.69) (envelope-from <csp@csperkins.org>) id 1TQGKF-00033l-3t; Mon, 22 Oct 2012 12:37:43 +0100
Mime-Version: 1.0 (Apple Message framework v1283)
Content-Type: multipart/alternative; boundary="Apple-Mail=_68F96868-F70B-432B-BCAD-93A31DDF2153"
From: Colin Perkins <csp@csperkins.org>
In-Reply-To: <FD4DC1EE-F3B9-46C9-ABD3-CAA59AB45EDB@tno.nl>
Date: Mon, 22 Oct 2012 12:37:42 +0100
Message-Id: <89C3B25E-7970-46DE-A26E-CABA6C1BB6EC@csperkins.org>
References: <CAEWORyfY+xZ-8LFnezmjcpjtg2ixCdNen5x0ZgPaRRF8XyzLnQ@mail.gmail.com> <FD4DC1EE-F3B9-46C9-ABD3-CAA59AB45EDB@tno.nl>
To: "Brandenburg, R. (Ray) van" <ray.vanbrandenburg@tno.nl>
X-Mailer: Apple Mail (2.1283)
X-BlackCat-Spam-Score: -12
X-Mythic-Debug: Threshold = On =
Cc: Magnus Westerlund <magnus.westerlund@ericsson.com>, "avt@ietf.org" <avt@ietf.org>
Subject: Re: [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: Mon, 22 Oct 2012 11:37:45 -0000

Hi Ray,

Thank you for your comments. These all look very reasonable. I'm about to submit a -10 version of the draft that should hopefully address them.

Colin


On 3 Aug 2012, at 03:22, Brandenburg, R. (Ray) van wrote:
> 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
> 
> _______________________________________________
> Audio/Video Transport Core Maintenance
> avt@ietf.org
> https://www.ietf.org/mailman/listinfo/avt



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