Re: [imapext] AD review of draft-ietf-imapapnd-appendlimit-extension-06

[Jayantheesh S B <[e-mail]>]

Hi Barry,

Thanks for the quick review comments. 

For Section 6, this was our reasoning behind the text

Say a server has a limit of 50 MB. Before this extension, an attacker first tries to APPEND 25 MB and it succeeds.
Then he tries  40MB and that too succeeds. Finally he tries 60 MB to find the limit of 
server and use that as start of attack. With this extension the attacker can find the limit in no time, making it easy for him to 
attack.

Regards,
Jay
-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On Behalf Of Barry Leiba
Sent: Thursday, December 17, 2015 5:03 PM
To: Jayantheesh S B
Cc: Narendra Bisht; Alexey Melnikov; [e-mail]; S Moonesamy ([e-mail]); S Moonesamy ([e-mail])
Subject: Re: [imapext] AD review of draft-ietf-imapapnd-appendlimit-extension-06

> Please find the latest version of the draft (version 07) attached. As 
> per the review discussion, we have updated the draft.
...
> We will upload the draft once if all the review comments has been addressed.

This looks mostly good, and thanks very much for all the work on this.
The ABNF and the Security Considerations still need a bit (see below).
Some editorial nits to fix, as well, before it's ready to post.
Below, "OLD" refers to text in the proposed -07 version.  Except for the ABNF and Security considerations, these are all very minor editorial things.

In the abstract, make it "APPEND commands" (plural).

In the Introduction:

OLD
   Several IMAP servers have limitation for mail upload size which is
   not published to the email client.  When email client APPEND a mail
   with huge attachments, using non-synchronizing literals it fails due
   to size restriction set by the IMAP server.
NEW
   Some IMAP servers have limits for mail upload size, and those limits
   are not published to the email client.  When the email client APPENDs
   a message with huge attachments, using non-synchronizing literals,
   the APPEND fails because of the upload limit, but the client has
   already sent the message data anyway.
END

In Section 3:

OLD
   IMAP server can have mailbox specific APPENDLIMIT value, which will
   not be advertised as part of CAPABILITY response.  The IMAP server
   can publish NIL for a mailbox to convey that there is no APPENDLIMIT
   to that mailbox [RFC4466].
NEW
   An IMAP server can have mailbox-specific APPENDLIMIT values, which
   will not be advertised as part of CAPABILITY response.  The IMAP
   server can publish specific values for each mailbox, and can publish
   "NIL" for a mailbox to convey that there is no APPENDLIMIT for that
   mailbox.
END

(I don't think there's any need for a citation to 4466 here; we'll have it below, by the ABNF.)

In the section titles of 3.1 and 3.2, make it "STATUS response to the"
(not "in the").  This was my error when I suggested the change; sorry.

Similarly, in Section 3.2 take out the word "emit", which was there in error.

In Section 5, I think you misunderstood Alexey's suggestion for using the 4466 changes.  Let's try this; Alexey, please check that I got this right:

Replace all the ABNF in Section 5 with this:

NEW
   capability /= "APPENDLIMIT" ["=" number]
               ;; capability is defined in RFC 3501

   status-att /= "APPENDLIMIT"
               ;; status-att is defined in RFC 3501

   status-att-val /= "APPENDLIMIT" SP (number / nil)
               ;; status-att-val is defined in RFC 4466 END

...and also make this change:

OLD
   [RFC3501] defines the non-terminals
   "capability", "resp-text-code" and "status-att".
NEW
   [RFC3501] defines the non-terminals
   "capability" and "status-att", and [RFC4466] defines
   "status-att-val".
END

Reasoning:
First, I think the extra level of indirection, making two lines per item, was only confusing.

Second, there seem to be three things you need to do: (1) add the capability string, (2) add the APPENDLIMIT status option, and (3) add the APPENDLIMIT status response.  Those three items do it.  I don't know why you had the addition to resp-text-code -- it was always the wrong thing to have, and we missed it before.

In the paragraph after the ABNF, change "A number indicating the fixed maximum" to "The number indicates the fixed maximum".

In Section 6, my comment about the security considerations still needs to be addressed.  You say this:

   The IMAP APPENDLIMIT extension described in this document can
   conceivably be used to facilitate Denial-of-Service attacks.
   Specifically, the information contained in the APPENDLIMIT capability
   and use of the APPEND command make it somewhat quicker and easier to
   devise an efficacious Denial-of-Service attack.  However, unless
   implementations are very weak, these extensions do not create any
   vulnerability that has not always existed with IMAP.

I still ask: Why does this information make it quicker and easier to do a DoS attack?  I don't see it, and the document needs to explain it clearly.  I can always, with or without this option, try to append a very large message using a non-synchronizing literal for the message data.  What is it about this extension that makes it quicker, easier, or more effective (I'd avoid the more obscure word "efficacious")?

Barry