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

Just to be clear, you're talking about an attack on APPEND from an 
authenticated user?

I think these sorts of attacks have different sorts of solutions, like 
blocking the account.


------ Original Message ------
From: "Jayantheesh S B" <[email protected]>
To: "Barry Leiba" <[email protected]>
Cc: "Alexey Melnikov" <[email protected]>; "Narendra Bisht" 
<[email protected]>; "S Moonesamy ([email protected])" 
<[email protected]>; "S Moonesamy ([email protected])" 
<[email protected]>; "[email protected]" <[email protected]>
Sent: 18/12/2015 11:57:27 a.m.
Subject: Re: [imapext] AD review of 
draft-ietf-imapapnd-appendlimit-extension-06

>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: [email protected] [mailto:[email protected]] On Behalf Of 
>Barry Leiba
>Sent: Thursday, December 17, 2015 5:03 PM
>To: Jayantheesh S B
>Cc: Narendra Bisht; Alexey Melnikov; [email protected]; S Moonesamy 
>([email protected]); S Moonesamy ([email protected])
>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
>_______________________________________________
>imapext mailing list
>[email protected]
>https://www.ietf.org/mailman/listinfo/imapext

_______________________________________________
imapext mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/imapext