Subject: Re: [secdir] SecDir review of draft-camarillo-rai-media-policy-dataset-01
From: Gonzalo Camarillo <[email-masked]>
To: Yaron Sheffer <[email-masked]>
Cc: "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
Date: Thu, 31 May 2012 13:06:42 +0300
List-Id: Security Area Directorate <secdir.ietf.org>

Hi Yaron,

thanks for reviewing the document. I will add the two references you
suggest in your last point to the next revision of the draft.

With respect to the remainder of your comments on the event package
document, that draft has already been in the RFC Editor's queue for a
while. So, at this point, we will not change it (although I would be
happy to replace that "should not" with a "SHOULD NOT" in AUTH48). Also,
SIP security is getting deployed on the field slowly as time goes by. It
is true that it is taking a while, but we are getting there.

Cheers,

Gonzalo

On 25/05/2012 7:07 PM, Yaron Sheffer wrote:
> 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.
> 
> Summary
> 
> Nothing much here - this is not where the security action is. However a 
> companion document may need some deeper security review.
> 
> Details
> 
> 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 
> (http://www.ietf.org/mail-archive/web/saag/current/msg03695.html) 
> 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, 
> <http://www.w3.org/TR/2006/REC-xinclude-20061115>.
> 
> Thanks,
>      Yaron
>