Re: [secdir] SECDIR Review of draft-ietf-morg-multimailbox-search-06

Barry Leiba <barryleiba@computer.org> Sat, 26 February 2011 14:47 UTC

Return-Path: <barryleiba@gmail.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 7F6B03A6944; Sat, 26 Feb 2011 06:47:46 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.879
X-Spam-Level:
X-Spam-Status: No, score=-102.879 tagged_above=-999 required=5 tests=[AWL=0.098, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
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 5Ym7kNLl16Tl; Sat, 26 Feb 2011 06:47:45 -0800 (PST)
Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by core3.amsl.com (Postfix) with ESMTP id 6A9E83A68D4; Sat, 26 Feb 2011 06:47:45 -0800 (PST)
Received: by iwl42 with SMTP id 42so2113047iwl.31 for <multiple recipients>; Sat, 26 Feb 2011 06:48:40 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=JZP2If7pLGDu2wTaWoEZRpA6mcFdhs6GZ9UEsl0maS0=; b=Wjug5uK0v4aacSIkwhY9rncQAuj5Q0rKAGoEB2OqZQJyEUyG8cmUIjXPHLV9h1Qi4U fPsrDhNlF28rRY4kREcwEd4s4vcKzwCe2DA4fpKpJ1AsjA36njMvaF8HJARNpGsMNPTS Y1MX6lLilmq/4rnIONMocRcFZmhey786WNh3E=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=Zg4WzDVPqHZf+Vrs4H1+xyAnniZgp9Yy8lvT8f71kmw7hp0gIl6+YjdEGlTdBKoRSp 7jmH2ldw/pLnfRcsU2jtperiOAjLcvf0ICLRHlAGS4YgExoGV5KLiKHVj0hAuYq1BH9k s1nUXvceypmFJewMPMSFi2JzfY7fvfrpoW0P8=
MIME-Version: 1.0
Received: by 10.42.213.194 with SMTP id gx2mr2351158icb.39.1298731720220; Sat, 26 Feb 2011 06:48:40 -0800 (PST)
Sender: barryleiba@gmail.com
Received: by 10.231.38.13 with HTTP; Sat, 26 Feb 2011 06:48:40 -0800 (PST)
In-Reply-To: <alpine.BSF.2.00.1102260635310.9639@fledge.watson.org>
References: <AANLkTi=dK8tZibPfR2F+s5rZ8OEsafgHBSk0_Ein-G0w@mail.gmail.com> <alpine.BSF.2.00.1102260635310.9639@fledge.watson.org>
Date: Sat, 26 Feb 2011 09:48:40 -0500
X-Google-Sender-Auth: V-kvS9fZe9T_GWQkVRqckYHc00A
Message-ID: <AANLkTim8Fmm9gBLY4vmopsZo6GimAM5ijb6bv5n6K1bk@mail.gmail.com>
From: Barry Leiba <barryleiba@computer.org>
To: Samuel Weiler <weiler@watson.org>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Cc: Alexey.Melnikov@isode.com, iesg@ietf.org, secdir@ietf.org
Subject: Re: [secdir] SECDIR Review of draft-ietf-morg-multimailbox-search-06
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: Sat, 26 Feb 2011 14:47:46 -0000

> If the user specifies some mailbox(es) which she doesn't have access rights
> to AND some mailbox(es) which she can access, the doc says to IGNORE the
> ones she can't access.  Wouldn't it be more useful to send an error for
> those mailboxes rather than silently fail?

Perhaps, but it seemed to be the consensus of the client folks that it
didn't matter, and it would be more useful to them to have the command
succeed as long as there were some "valid" mailboxes in the list.  We
could allow the command to succeed and return results for the good
mailboxes, and untagged error responses to indicate the bad ones.  But
we'd only want that for ones explicitly specified, not those that are
implicitly included.

For example, using the command from the example:

C: tag1 ESEARCH IN (mailboxes "folder1" subtree "folder2") unseen

If "folder1" or "folder2" doesn't exist (or the user has no access),
notification of that might be appropriate.  But if, say, "folder2/aaa"
and "folder2/bbb" both exist and the user has access to the former and
not the latter, sending an error for "folder2/bbb" would give away
information.  We wouldn't want this to become a way to probe for
mailbox names.

Apart from that, we'd have to define a new way to indicate the
situation, perhaps with a further extension to the ESEARCH response.
We have a response code "NONEXISTENT" that we can use for single
mailboxes, putting it on a tagged or untagged "NO":

C: tag1 RENAME folder1 folderX
S: tag1 NO [NONEXISTENT] failed because folder1 doesn't exist

But if you get this:
C: tag1 ESEARCH IN (mailboxes "folder1" subtree "folder2") unseen
S: * NO [NONEXISTENT] failed because folder1 doesn't exist
S: * ESEARCH (TAG "tag1" MAILBOX "folder2" UIDVALIDITY 1) UID ALL
   4001,4003,4005,4007,4009
S: tag1 OK done

...then the client doesn't know which mailbox(es) failed, because the
text after the response code isn't machine parsable.  We'd have to
extend the ESEARCH response for it, somewhat like this:

S: * ESEARCH [NONEXISTENT] (TAG "tag1" MAILBOX "folder1")

We could certainly do that, but given that the only ways this can
happen is through a serious client bug or another client's deleting or
renaming "folder1" out from under this client, that the latter doesn't
actually happen very often, that client developers have already told
us that they don't care, and that clients that get it wrong may expose
information about inaccessible mailboxes... it's best to leave it as
it is.

> Are there any other IMAP commands that access multiple mailboxes at once?
>  If not, if might be worth repeating some of the text in section 2, just to
> call out the new case that must be checked.

Apart from LIST, this is the first such IMAP command.  I'd be happy to
repeat or refer to some of the text from section 2 in the security
considerations.

Barry