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

From: Barry Leiba <[email-masked]>
Date: Wed, 15 Dec 2010 10:58:27 -0500

(Adding the MORG mailing list.)

On Wed, Dec 15, 2010 at 10:04, Sean Turner <[email-masked]> 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

---

From: Adrian Farrel <[email-masked]>
Date: Wed, 15 Dec 2010 18:48:15 +0000

Hi,

Thanks for the update.

[SNIP]

> someone over the edge to using TLS, where it was OK not to use TLS

A way to handle this is to point it out. It is not the document authors' job in
this sort of case to tell the deployer what to do. But it is the their job to
say, look, when you are doing this new feature you are increasing your exposure
and if that worries you, you need to do the security stuff.

That is, IMHO, it is not the authors' position to say how likely this is to tip
someone into using TLS. Just set out the facts and point out that TLS exists and
let people decide for themselves.

A

---

From: Alexey Melnikov <[email-masked]>
Date: Fri, 17 Dec 2010 22:03:41 +0000

>let people decide for themselves.
I negotiated some text with Barry on this.