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

From: Chris Lonvick <[email-masked]>
Date: Mon, 13 Dec 2010 14:52:38 -0800 (PST)

Hi,

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.

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.  :)

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.

If this could happen, then a line or two in the Security Considerations 
section to alert the reader to this potential threat would address my 
concern.

Other than that, I find the document to be of good quality and ready to be 
discussed by the IESG.

Thanks,
Chris

---

From: Barry Leiba <[email-masked]>
Date: Mon, 13 Dec 2010 21:05:37 -0500

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.

> 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 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?

Barry

---

From: Chris Lonvick <[email-masked]>
Date: Tue, 14 Dec 2010 13:39:07 -0800 (PST)

Hi Barry,

>   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.

> 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

---

From: Barry Leiba <[email-masked]>
Date: Tue, 14 Dec 2010 17:15:49 -0500

> 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.

It's already in my working copy for the next rev.

Barry