[secdir] SecDir review of draft-camarillo-rai-media-policy-dataset-01

Yaron Sheffer <yaronf.ietf@gmail.com> Fri, 25 May 2012 16:08 UTC

Return-Path: <yaronf.ietf@gmail.com>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id F300E21F8744; Fri, 25 May 2012 09:08:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.01
X-Spam-Status: No, score=-103.01 tagged_above=-999 required=5 tests=[AWL=0.589, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id HQtzEzvwZFqB; Fri, 25 May 2012 09:08:06 -0700 (PDT)
Received: from mail-bk0-f44.google.com (mail-bk0-f44.google.com []) by ietfa.amsl.com (Postfix) with ESMTP id 0682D21F873E; Fri, 25 May 2012 09:08:05 -0700 (PDT)
Received: by bkty8 with SMTP id y8so1057214bkt.31 for <multiple recipients>; Fri, 25 May 2012 09:08:05 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject :content-type:content-transfer-encoding; bh=dldxR/kvpHWc3gBRkhx8boZHdiIfn4xK2GhG3E2da0I=; b=UpgDH9IKq7MajkMLMFlH8LOexzZPOxHwAilpV+DI3Krm+E1QCEv8VGI9ZIodhrgtOW N78UmAyK8shtkPFCiRr9Zd8zvzPfFjagr7qu6t0LxG3zzI1T2AAYZbn2Ss2hBfBabc5C +TNCU3apGQMyrAw1R0zCKenTn60/2U5HrRsz7H7V+/+FuF7PYEbGCHPIywoSJXp0O8dZ Tc/vGSSa5kPrt8K+PXbdHLA74akAMMyRArKLN3cL9iTXpiahdFGOuQfb3GEKa0DH8NSP T5sc3mTQW3Dhfub+TJ7pB/DKEyc9BGHHkrtnt24F4LDOV+gozCfgLBKc0oanCdReI2ho 1+2w==
Received: by with SMTP id u24mr1572621bkw.75.1337962085045; Fri, 25 May 2012 09:08:05 -0700 (PDT)
Received: from [] ([]) by mx.google.com with ESMTPS id 9sm7002559bku.9.2012. (version=SSLv3 cipher=OTHER); Fri, 25 May 2012 09:08:03 -0700 (PDT)
Message-ID: <4FBFAE5F.8010305@gmail.com>
Date: Fri, 25 May 2012 19:07:59 +0300
From: Yaron Sheffer <yaronf.ietf@gmail.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:12.0) Gecko/20120430 Thunderbird/12.0.1
MIME-Version: 1.0
To: secdir@ietf.org, draft-camarillo-rai-media-policy-dataset.all@tools.ietf.org, iesg@ietf.org
Content-Type: text/plain; charset="windows-1252"; format="flowed"
Content-Transfer-Encoding: 8bit
Subject: [secdir] SecDir review of draft-camarillo-rai-media-policy-dataset-01
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: Fri, 25 May 2012 16:08:07 -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.


Nothing much here - this is not where the security action is. However a 
companion document may need some deeper security review.


This draft defines the contents/format of a media document. The document 
allows a SIP policy server to dictate the media policy that should be 
implemented by a UA, in general or on a per-session basis.

• The draft requires that all documents be well-formed and valid XML, 
which is good - not only for security.
• The real security stuff is in draft-ietf-sipping-policy-package-08. I 
will not review that document here, but I find it puzzling that session 
(media) information is transmitted/secured along with session encryption 
keys. Mixing together data of such disparate security sensitivity levels 
is likely to result in either over-engineering or under-security.
• Reading further down the said security considerations, this issue is 
addressed ("the user agent should not insert" etc.), but none of that 
discussion is normative!
• Moreover, recent discussion on SAAG 
suggests that some of the security solutions mandated by the Policy 
Package draft as well as the current draft are, to put it mildly, not 
widely implemented.
•  Back to the current document. Re: XML security considerations, please 
reference the security considerations of RFC 3470, and possibly also: 
Marsh, J., Orchard, D., and D. Veillard, "XML Inclusions (XInclude) 
Version 1.0 (Second Edition)", World Wide Web Consortium Recommendation 
REC-xinclude-20061115, November 2006,