[secdir] secdir review of draft-ietf-calext-extensions-03

"Xialiang (Frank)" <frank.xialiang@huawei.com> Wed, 22 June 2016 01:39 UTC

Return-Path: <frank.xialiang@huawei.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 75C0012D871; Tue, 21 Jun 2016 18:39:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.646
X-Spam-Status: No, score=-5.646 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id 2u9-_UPTtrbG; Tue, 21 Jun 2016 18:39:16 -0700 (PDT)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com []) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3793112D86E; Tue, 21 Jun 2016 18:39:15 -0700 (PDT)
Received: from (EHLO lhreml701-cah.china.huawei.com) ([]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CRG43580; Wed, 22 Jun 2016 01:39:13 +0000 (GMT)
Received: from SZXEMA418-HUB.china.huawei.com ( by lhreml701-cah.china.huawei.com ( with Microsoft SMTP Server (TLS) id; Wed, 22 Jun 2016 02:39:11 +0100
Received: from SZXEMA502-MBS.china.huawei.com ([]) by SZXEMA418-HUB.china.huawei.com ([]) with mapi id 14.03.0235.001; Wed, 22 Jun 2016 09:39:07 +0800
From: "Xialiang (Frank)" <frank.xialiang@huawei.com>
To: "'iesg@ietf.org'" <iesg@ietf.org>, "'secdir@ietf.org'" <secdir@ietf.org>, "draft-ietf-calext-extensions.all@tools.ietf.org" <draft-ietf-calext-extensions.all@tools.ietf.org>
Thread-Topic: secdir review of draft-ietf-calext-extensions-03
Thread-Index: AdHMJtfMw7OBPuxATBmrOMqiIbTB8g==
Date: Wed, 22 Jun 2016 01:39:06 +0000
Message-ID: <C02846B1344F344EB4FAA6FA7AF481F12AF5D0BA@SZXEMA502-MBS.china.huawei.com>
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
x-originating-ip: []
Content-Type: multipart/alternative; boundary="_000_C02846B1344F344EB4FAA6FA7AF481F12AF5D0BASZXEMA502MBSchi_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A090203.5769EC41.0043, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32
X-Mirapoint-Loop-Id: 973470c426d6eb18bee7eb455cca75fe
Archived-At: <https://mailarchive.ietf.org/arch/msg/secdir/wiYaQFnwlww1ONN53S5tjiOcXPk>
Subject: [secdir] secdir review of draft-ietf-calext-extensions-03
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.17
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: <https://mailarchive.ietf.org/arch/browse/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: Wed, 22 Jun 2016 01:39:17 -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.

This document defines a set of new properties for iCalendar data as well as extending the use of some existing properties to the entire iCalendar object.

In general, since this document just defines several new properties and extends some existing properties with new parameters for the iCalendar object, there are limited new threats brought by this work which are covered in the "Security Considerations" section.

Summary: this document appears in reasonably good shape, with minor issues that should be addressed before publication.

Below is a series of my comments, nits for your consideration.

section 7
1. This section covers the possible new threats brought by new properties and parameters, but does not mention how to mitigate them explicitly. Could you consider this point?
2. The "Security Considerations" section of [RFC5545] describes the general security issues and its corresponding relation with the transport protocol. It's clear and comprehensive. As the extension draft to the iCalendar object specification, it's a good practice to mention that the security considerations in [RFC5545] continue to apply in this document.

section 5.2--5.6
These sections specify the extensive properties, and don't follow the template in [RFC5545]. Would it be better to have some text for each extensive property to point out its original specification in [RFC5545] for easy understanding?

section 5.11
The new property -- conference, is missed in the previous iCalendar components' definition in section 4;

Section 8.1
The section number of [RFC5545] referenced here is wrong, it should be modified from 8.2.3 to 8.3.2;

Section 8.2
The section number of [RFC5545] referenced here is wrong, it should be modified from 8.2.4 to 8.3.3;