Secdir review of draft-daboo-imap-annotatemore-13

Kurt Zeilenga <Kurt.Zeilenga@Isode.com> Wed, 30 April 2008 23:04 UTC

Return-Path: <ietf-bounces@ietf.org>
X-Original-To: ietf-archive@megatron.ietf.org
Delivered-To: ietfarch-ietf-archive@core3.amsl.com
Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 253993A6B24; Wed, 30 Apr 2008 16:04:34 -0700 (PDT)
X-Original-To: ietf@core3.amsl.com
Delivered-To: ietf@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 349563A6C26 for <ietf@core3.amsl.com>; Wed, 30 Apr 2008 16:04:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.449
X-Spam-Level:
X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599]
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 mYMnraKwRwgO for <ietf@core3.amsl.com>; Wed, 30 Apr 2008 16:04:26 -0700 (PDT)
Received: from boole.openldap.org (boole.openldap.org [IPv6:2001:4f8:3:ba:2e0:18ff:fe02:efec]) by core3.amsl.com (Postfix) with ESMTP id 6C9CE3A6B24 for <ietf@ietf.org>; Wed, 30 Apr 2008 16:04:26 -0700 (PDT)
Received: from [192.168.1.198] (75-141-230-206.dhcp.nv.charter.com [75.141.230.206] (may be forged)) (authenticated bits=0) by boole.openldap.org (8.13.8/8.13.8) with ESMTP id m3UN4JYf020294 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 30 Apr 2008 23:04:25 GMT (envelope-from Kurt.Zeilenga@Isode.com)
Message-Id: <50583ED8-AF38-408E-B3E3-4A4124F3AB9C@Isode.com>
From: Kurt Zeilenga <Kurt.Zeilenga@Isode.com>
To: Cyrus Daboo <cyrus@daboo.name>, Alexey Melnikov <alexey.melnikov@Isode.com>, Chris Newman <Chris.Newman@Sun.COM>
Mime-Version: 1.0 (Apple Message framework v919.2)
Subject: Secdir review of draft-daboo-imap-annotatemore-13
Date: Wed, 30 Apr 2008 16:04:19 -0700
X-Mailer: Apple Mail (2.919.2)
Cc: secdir@mit.edu, IETF discussion list <ietf@ietf.org>
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: IETF Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

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 others should treat  
these comments just like any other comments.

This document defines an extension to IMAP [RFC3501] to allow metadata  
(or annotations) to attached to and read from various objects.  I see  
no serious problems with this draft, but do have some comments.

I think the second consideration might better be stated first and  
worded not only to discuss arbitrary data, not just data of arbitrary  
size.  Hence, an attacker can not only use this as an avenue for a  
denial of service attacks upon servers and upon the clients of any  
user, but can use the mechanism to mount a wider range of attacks upon  
servers and clients.  I recommend this be called out even if this  
issue exists in the base protocol.

There should be some discussion of any possible privacy concerns  
regarding any of the defined entries.   Also, when you say "all users  
of the system", do you really mean all?  Some implementors might take  
this as precluding use of access controls to restrict who sees what.   
It might be better to drop replace "all" with "authorized".

A couple of non security related comments:

I assume text/plain entries can span multiple lines.  It would be good  
to include a multi-line example in the document.  Also, an octet  
string example might be useful.

It might be good for /public/admin to allow multiple URIs, with  
comments, to be provided.  For instance,
	Admin <admin@example.com>
	24-hour hotline <tel:18005550000>
	Issue Tracker <http://example.com/tracker>

Regards, Kurt
_______________________________________________
IETF mailing list
IETF@ietf.org
https://www.ietf.org/mailman/listinfo/ietf