[MORG] Discuss and Comment positions on draft-ietf-morg-list-specialuse-05

[Barry Leiba <[e-mail]>]

(Adding the MORG mailing list.)

On Wed, Dec 15, 2010 at 10:04, Sean Turner <[e-mail]> wrote:
> This is a modified position.  I've removed those that have been addressed.
> The remaining two will be cleared after the RFC editor's note/new version
> has been posted:
>
> #2) Are there any security considerations with combining special-use to the
> metadata extension?
>
> #3) There's also some text Barry & Chris have agreed to incorporate based
> on Chris' SECDIR review:
> http://www.ietf.org/mail-archive/web/secdir/current/msg02277.html

I've just submitted an -06 version that has the new paragraph in the
security considerations, as discussed with Chris, and that also
mentions metadata along with CREATE USE.

This version also addresses Ralph's non-blocking comment with this change:

   All of the above attributes are OPTIONAL, and any given server or
   message store may support any combination of the attributes, or none
   at all.  In most cases there will likely be at most one mailbox with
   a given attribute for a given user, but in some server or message
   store implementations it might be possible for multiple mailboxes to
   have the same special-use attribute.

Also, in response to Adrian's non-blocking comment, I've lower-cased
the words "may" and "optional" in the abstract and introduction.  On
capitali[s/z]ing the section headings, I guess the RFC editor will
decide the style here.  Adrian made one more point in his comment:

> Section 7
>
 >  LIST response: There are no security issues with conveying special-
 >  use information to a client.
>
> Really. Doesn't the exchange of information imply that there is
> potential to intercept the information. Knowledge of the message store
> usage may be valuable to someone attempting to access messages.

If someone can tap into the IMAP stream, this extra bit of information
(which will much of the time be guessable from the mailbox name
anyway) is the least of anyone's concern.  I don't believe there are
any security issues here beyond what exist in IMAP in the first place.
 I certainly don't think it's the case that *this* is what will push
someone over the edge to using TLS, where it was OK not to use TLS
before.

Barry