Re: [secdir] secdir review of draft-ietf-morg-list-specialuse-05

Chris Lonvick <clonvick@cisco.com> Tue, 14 December 2010 21:37 UTC

Return-Path: <clonvick@cisco.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 9AAE028C100; Tue, 14 Dec 2010 13:37:27 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -110.499
X-Spam-Level:
X-Spam-Status: No, score=-110.499 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, 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 4JJjTpTsWN5w; Tue, 14 Dec 2010 13:37:26 -0800 (PST)
Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by core3.amsl.com (Postfix) with ESMTP id B5B3428C138; Tue, 14 Dec 2010 13:37:26 -0800 (PST)
Authentication-Results: sj-iport-4.cisco.com; dkim=neutral (message not signed) header.i=none
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AvsEADtzB02rR7H+/2dsb2JhbACkE3imWJs8hUoEhGQ
X-IronPort-AV: E=Sophos;i="4.59,344,1288569600"; d="scan'208";a="232645282"
Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-4.cisco.com with ESMTP; 14 Dec 2010 21:39:07 +0000
Received: from sjc-cde-011.cisco.com (sjc-cde-011.cisco.com [171.69.16.68]) by sj-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id oBELd7Ih028152; Tue, 14 Dec 2010 21:39:07 GMT
Date: Tue, 14 Dec 2010 13:39:07 -0800
From: Chris Lonvick <clonvick@cisco.com>
To: Barry Leiba <barryleiba@computer.org>
In-Reply-To: <AANLkTinpp7w8PYmXgN7Jj=wpM7F_fJ7QcaAxUk0y5jny@mail.gmail.com>
Message-ID: <Pine.GSO.4.63.1012141331070.28052@sjc-cde-011.cisco.com>
References: <Pine.GSO.4.63.1012091802500.17916@sjc-cde-011.cisco.com> <AANLkTinpp7w8PYmXgN7Jj=wpM7F_fJ7QcaAxUk0y5jny@mail.gmail.com>
MIME-Version: 1.0
Content-Type: MULTIPART/MIXED; BOUNDARY="-559023410-2110444415-1292362747=:28052"
Cc: draft-ietf-morg-list-specialuse.all@tools.ietf.org, iesg@ietf.org, secdir@ietf.org
Subject: Re: [secdir] secdir review of draft-ietf-morg-list-specialuse-05
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, 14 Dec 2010 21:37:27 -0000

Hi Barry,

On Mon, 13 Dec 2010, Barry Leiba wrote:

> Hi, Chris, and thanks for the review.
>
>> I am not altogether familiar with the placement of IMAP mailboxes to have a
>> solid grasp on the subject.  Please take my comments with a grain of salt.
>>  :)
>
> Noted.
>
>> You mention at the end of Section 2 that users may configure shared
>> mailboxes.  Does that imply that mailboxes are not normally shared, and
>> would then mean that another user would not have any access to any of the
>> mailboxes identified by IMAP unless they were specifically given a common,
>> shared mailbox?
>>
>> An example of my concern is that the \Junk mailbox may be configured to be
>> common to all the users.  In some cases, a legitimate piece of mail may be
>> incorrectly marked as spam by a filter and then placed into the Junk bin. If
>> that were to happen, anyone who had access to that mailbox would be able to
>> see the contents of that email.
>
> Personal IMAP mailboxes are normally private.  Users may also have
> access to public mailboxes (say, archives of mailing lists, or netnews
> collections), to group mailboxes (our department's "to-do" folder), or
> to personal mailboxes of others that have been explicitly shared.
> These are usually presented in a separate namespace from the personal
> mailboxes.
>
> Your concern is reflected in the second paragraph in the Security
> Considerations:
>
>   CREATE command "USE" parameter: In some server implementations, some
>   special uses may imply automatic action by the server.  For example,
>   creation of a "\Junk" mailbox might cause the server to start placing
>   messages that have been evaluated as spam into the mailbox.
>   Implementors SHOULD consider the consequences of allowing a user (or
>   client program) to designate the target of such automatic action.

I didn't see what I was talking about (more-r-less access control) in that 
paragraph.  It looked more like a warning about automated processes as it 
doesn't seem to imply that the \Junk mailbox would be shared.

>
> I can make this more explicit, if you think that's important, by
> adding another paragraph:
>
>   Example: If a user is allowed to give the "\Junk" attribute to a
> shared mailbox,
>   legitimate mail that's misclassified as junk (false positives) will
> be put into that
>   shared mailbox, exposing the user's private mail to others.  The server might
>   warn a user of that possibility, or might refuse to allow the
> specification to be
>   made on a shared mailbox.  (Note that this problem exists independent of this
>   specification, if the server allows a user to share a mailbox
> that's already in use
>   for such a function.)
>
> Does that help, do you think?

Personally, I think being expicit about this helps.  Your explanation 
ebove helps me as well.

I'd like to see it in there but if you, or others feel that people 
familiar enough with IMAP to implement this don't need this extra warning, 
then I won't push it.

Regards,
Chris

>
> Barry
>