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

From: Phillip Hallam-Baker <[email-masked]>
Date: Tue, 22 Feb 2011 08:07:23 -0500

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 makes a minor adjustment to the search mechanism of imap,
allowing searches to be made slightly more efficiently.

As such, the only security concern that is impacted is resource consumption
which is appropriately called out in the specification.

-- 
Website: http://hallambaker.com/

---

From: Samuel Weiler <[email-masked]>
Date: Sat, 26 Feb 2011 06:43:25 -0500 (EST)

On Tue, 22 Feb 2011, Phillip Hallam-Baker wrote:

> This document makes a minor adjustment to the search mechanism of 
> imap, allowing searches to be made slightly more efficiently.

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?

Also, the security considerations says:

    Implementations MUST, of course, apply access controls appropriately,
    limiting a user's access to ESEARCH in the same way its access is
    limited for any other IMAP commands.  This extension has no data-
    access risks beyond what may be there in the unextended IMAP
    implementation.

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.

---

From: Barry Leiba <[email-masked]>
Date: Sat, 26 Feb 2011 09:48:40 -0500

> 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