[secdir] secdir Review of draft-ietf-ppsp-problem-statement

Russ Mundy <mundy@sparta.com> Thu, 15 December 2011 05:05 UTC

Return-Path: <mundy@sparta.com>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A607721F8ABD; Wed, 14 Dec 2011 21:05:26 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
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 zYZsfUjJ57KU; Wed, 14 Dec 2011 21:05:26 -0800 (PST)
Received: from M4.sparta.com (M4.sparta.com [157.185.61.2]) by ietfa.amsl.com (Postfix) with ESMTP id DF18921F8ABB; Wed, 14 Dec 2011 21:05:25 -0800 (PST)
Received: from Beta5.sparta.com (beta5.sparta.com [157.185.63.21]) by M4.sparta.com (8.14.4/8.14.4) with ESMTP id pBF55PaO012823; Wed, 14 Dec 2011 23:05:25 -0600
Received: from mailbin2.ads.sparta.com (mailbin.sparta.com [157.185.85.6]) by Beta5.sparta.com (8.13.8/8.13.8) with ESMTP id pBF55NBA025264; Wed, 14 Dec 2011 23:05:23 -0600
Received: from spiff.tislabs.com ([192.94.214.200]) by mailbin2.ads.sparta.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Thu, 15 Dec 2011 00:05:23 -0500
Received: from ubvm (unknown [10.66.1.77]) by spiff.tislabs.com (Postfix) with ESMTPS id C93CD5B51424; Thu, 15 Dec 2011 00:05:22 -0500 (EST)
Received: from [127.0.0.1] (ubvm [172.16.115.10]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: mundy) by ubvm (Postfix) with ESMTPSA id B0A4F27EFE8; Thu, 15 Dec 2011 00:05:21 -0500 (EST)
From: Russ Mundy <mundy@sparta.com>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Date: Thu, 15 Dec 2011 00:05:19 -0500
Message-Id: <B5B0B57F-4C24-475B-B92B-4B3D4A64C13A@sparta.com>
To: iesg@ietf.org, secdir@ietf.org, draft-ietf-ppsp-problem-statement-all@tools.ietf.org
Mime-Version: 1.0 (Apple Message framework v1084)
X-Mailer: Apple Mail (2.1084)
X-OriginalArrivalTime: 15 Dec 2011 05:05:23.0428 (UTC) FILETIME=[2692FA40:01CCBAE7]
Cc: Russ Mundy <mundy@sparta.com>
Subject: [secdir] secdir Review of draft-ietf-ppsp-problem-statement
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/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, 15 Dec 2011 05:05:26 -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.

The document has more of a "marketing" tone to it than most IETF documents and, as such, seems more like a "why do we need to do this ppsp protocol" (or protocol suite?) than a problem statement.  On the other hand, if the working group believes that publishing this information will help with reaching their goals or providing context to potential future implementers of actual protocol specifications, I don't see any reason not to publish it - as long as it remains Informational.

With respect to the security considerations section, the information seems to be good particularly since the document itself covers a wide range of potential protocol specifications.  Requiring subsequent specifications to address specific threats and mitigations is good but it would also be good for these specifications to document specific security requirements for the protocols as well as the threats.  Additionally, specifically excluding support for a particular requirement (Digital Rights Management (DRM)) does not seem to make sense in this document since it claims to be a problem statement - this sounds much more like the statement of a non-requirement than a security consideration and should be in some requirements document or the requirements section of protocol specifications.

Russ Mundy