Re: [secdir] Secdir review of draft-ietf-xcon-event-package-01

Gonzalo Camarillo <Gonzalo.Camarillo@ericsson.com> Tue, 24 February 2009 13:47 UTC

Return-Path: <gonzalo.camarillo@ericsson.com>
X-Original-To: secdir@core3.amsl.com
Delivered-To: secdir@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8BB483A67A2; Tue, 24 Feb 2009 05:47:05 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.249
X-Spam-Level:
X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S-52fMYp+Vxd; Tue, 24 Feb 2009 05:47:04 -0800 (PST)
Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id 855F73A68A6; Tue, 24 Feb 2009 05:47:04 -0800 (PST)
Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 2761122408; Tue, 24 Feb 2009 14:47:20 +0100 (CET)
X-AuditID: c1b4fb3e-ad0bdbb000001315-36-49a3fa60d34b
Received: from esealmw129.eemea.ericsson.se (unknown [153.88.253.125]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 791EA22218; Tue, 24 Feb 2009 14:47:12 +0100 (CET)
Received: from esealmw129.eemea.ericsson.se ([153.88.254.177]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 24 Feb 2009 14:47:10 +0100
Received: from [131.160.126.174] ([131.160.126.174]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 24 Feb 2009 14:47:10 +0100
Message-ID: <49A3FA5E.4010405@ericsson.com>
Date: Tue, 24 Feb 2009 15:47:10 +0200
From: Gonzalo Camarillo <Gonzalo.Camarillo@ericsson.com>
User-Agent: Thunderbird 2.0.0.19 (Windows/20081209)
MIME-Version: 1.0
To: Yaron Sheffer <yaronf@checkpoint.com>
References: <7F9A6D26EB51614FBF9F81C0DA4CFEC8D97E66FC8E@il-ex01.ad.checkpoint.com>
In-Reply-To: <7F9A6D26EB51614FBF9F81C0DA4CFEC8D97E66FC8E@il-ex01.ad.checkpoint.com>
Content-Type: text/plain; charset="windows-1252"; format="flowed"
Content-Transfer-Encoding: 8bit
X-OriginalArrivalTime: 24 Feb 2009 13:47:10.0466 (UTC) FILETIME=[6405DE20:01C99686]
X-Brightmail-Tracker: AAAAAA==
Cc: "draft-ietf-xcon-event-package@tools.ietf.org" <draft-ietf-xcon-event-package@tools.ietf.org>, "alan@sipstation.com" <alan@sipstation.com>, "adam@nostrum.com" <adam@nostrum.com>, "iesg@ietf.org" <iesg@ietf.org>, "secdir@ietf.org" <secdir@ietf.org>
Subject: Re: [secdir] Secdir review of draft-ietf-xcon-event-package-01
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/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: Tue, 24 Feb 2009 13:47:05 -0000

Hi Yaron,

thanks for your review.

With respect to your comment, it is common to specify that documents 
SHOULD be valid. Note that RFC 5261 (this draft is based on it) also 
specifies documents that SHOULD be valid. Therefore, we chose to keep 
the SHOULD given that this is an extension to RFC 5261.

Thanks,

Gonzalo

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.
> 
>  
> 
> This draft extends the existing SIP conference package by adding 
> additional functionality (the XCON data model) and XML document patching.
> 
>  
> 
> The Security Considerations section references predecessor documents, 
> and this seems reasonable to me.
> 
>  
> 
> One functionality comment, with security implications: Sec. 5.3 
> specifies that a “patch” document MUST be well formed and SHOULD be 
> valid. I believe non-valid documents significantly increase the 
> vulnerability “attack surface”. And since the “patch” schema is 
> extensible by design, I see no reason to not validate the document. In 
> other words, please consider changing validation to a MUST.
> 
>  
> 
> Thanks,
> 
>             Yaron
> 
> 
> 
> Email secured by Check Point
>