Re: [imapext] AD review of draft-ietf-imapapnd-appendlimit-extension-06
"Adrien de Croy" <adrien@qbik.com> Thu, 17 December 2015 23:16 UTC
Return-Path: <adrien@qbik.com>
X-Original-To: imapext@ietfa.amsl.com
Delivered-To: imapext@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 391591B2BAE for <imapext@ietfa.amsl.com>; Thu, 17 Dec 2015 15:16:44 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.6
X-Spam-Level:
X-Spam-Status: No, score=-1.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HOST_MISMATCH_COM=0.311, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4eaiCFSUaOgc for <imapext@ietfa.amsl.com>; Thu, 17 Dec 2015 15:16:42 -0800 (PST)
Received: from BODYBAG.qbik.local (smtp.qbik.com [122.56.26.1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3DD761A01EC for <imapext@ietf.org>; Thu, 17 Dec 2015 15:16:40 -0800 (PST)
Received: From [192.168.1.146] (unverified [192.168.1.146]) by SMTP Server [192.168.1.146] (WinGate SMTP Receiver v7.0.0 (Build 1)) with SMTP id <0000000037@BODYBAG.qbik.local>; Fri, 18 Dec 2015 12:16:29 +1300
From: Adrien de Croy <adrien@qbik.com>
To: Jayantheesh S B <j.sb@sea.samsung.com>, Barry Leiba <barryleiba@computer.org>
Date: Thu, 17 Dec 2015 23:16:28 +0000
Message-Id: <embf04f92a-8a6e-4a94-9836-1fe2719968bc@bodybag>
In-Reply-To: <4c5100ed28d442ad89a5a25028d10c8f@SEAMBX01.sea.samsung.com>
User-Agent: eM_Client/6.0.23421.0
Mime-Version: 1.0
Content-Type: text/plain; format="flowed"; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <http://mailarchive.ietf.org/arch/msg/imapext/q0rw5lOg9euLjRFe1J4VQrLei6M>
Cc: Alexey Melnikov <alexey.melnikov@isode.com>, Narendra Bisht <ns.bisht@sea.samsung.com>, "S Moonesamy (sm+ietf@elandnews.com)" <sm+ietf@elandnews.com>, "S Moonesamy (sm+ietf@elandsys.com)" <sm+ietf@elandsys.com>, "imapext@ietf.org" <imapext@ietf.org>
Subject: Re: [imapext] AD review of draft-ietf-imapapnd-appendlimit-extension-06
X-BeenThere: imapext@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: Adrien de Croy <adrien@qbik.com>
List-Id: Discussion of IMAP extensions <imapext.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/imapext>, <mailto:imapext-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/imapext/>
List-Post: <mailto:imapext@ietf.org>
List-Help: <mailto:imapext-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/imapext>, <mailto:imapext-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 17 Dec 2015 23:16:44 -0000
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" <j.sb@sea.samsung.com> To: "Barry Leiba" <barryleiba@computer.org> Cc: "Alexey Melnikov" <alexey.melnikov@isode.com>; "Narendra Bisht" <ns.bisht@sea.samsung.com>; "S Moonesamy (sm+ietf@elandnews.com)" <sm+ietf@elandnews.com>; "S Moonesamy (sm+ietf@elandsys.com)" <sm+ietf@elandsys.com>; "imapext@ietf.org" <imapext@ietf.org> 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: barryleiba@gmail.com [mailto:barryleiba@gmail.com] On Behalf Of >Barry Leiba >Sent: Thursday, December 17, 2015 5:03 PM >To: Jayantheesh S B >Cc: Narendra Bisht; Alexey Melnikov; imapext@ietf.org; S Moonesamy >(sm+ietf@elandsys.com); S Moonesamy (sm+ietf@elandnews.com) >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 >imapext@ietf.org >https://www.ietf.org/mailman/listinfo/imapext
- [imapext] AD review of draft-ietf-imapapnd-append… Barry Leiba
- Re: [imapext] AD review of draft-ietf-imapapnd-ap… Barry Leiba
- [imapext] Referencing RFC 2088 (was: AD review of… S Moonesamy
- Re: [imapext] Referencing RFC 2088 Alexey Melnikov
- Re: [imapext] Referencing RFC 2088 (was: AD revie… Adrien de Croy
- Re: [imapext] AD review of draft-ietf-imapapnd-ap… Jayantheesh S B
- Re: [imapext] AD review of draft-ietf-imapapnd-ap… Narendra Bisht
- Re: [imapext] Referencing RFC 2088 S Moonesamy
- Re: [imapext] AD review of draft-ietf-imapapnd-ap… Alexey Melnikov
- Re: [imapext] Referencing RFC 2088 (was: AD revie… Naren
- Re: [imapext] AD review of draft-ietf-imapapnd-ap… S Moonesamy
- Re: [imapext] AD review of draft-ietf-imapapnd-ap… Naren
- Re: [imapext] AD review of draft-ietf-imapapnd-ap… S Moonesamy
- Re: [imapext] AD review of draft-ietf-imapapnd-ap… Naren
- Re: [imapext] AD review of draft-ietf-imapapnd-ap… Alexey Melnikov
- Re: [imapext] AD review of draft-ietf-imapapnd-ap… Alexey Melnikov
- Re: [imapext] AD review of draft-ietf-imapapnd-ap… Jayantheesh S B
- Re: [imapext] AD review of draft-ietf-imapapnd-ap… S Moonesamy
- Re: [imapext] AD review of draft-ietf-imapapnd-ap… Barry Leiba
- Re: [imapext] AD review of draft-ietf-imapapnd-ap… S Moonesamy
- Re: [imapext] AD review of draft-ietf-imapapnd-ap… Jayantheesh S B
- Re: [imapext] AD review of draft-ietf-imapapnd-ap… Jayantheesh S B
- Re: [imapext] AD review of draft-ietf-imapapnd-ap… S Moonesamy
- Re: [imapext] AD review of draft-ietf-imapapnd-ap… Stu Brandt
- Re: [imapext] AD review of draft-ietf-imapapnd-ap… Jayantheesh S B
- Re: [imapext] AD review of draft-ietf-imapapnd-ap… Adrien de Croy
- Re: [imapext] AD review of draft-ietf-imapapnd-ap… Adrien de Croy
- Re: [imapext] AD review of draft-ietf-imapapnd-ap… Stu Brandt
- Re: [imapext] AD review of draft-ietf-imapapnd-ap… Adrien de Croy
- Re: [imapext] AD review of draft-ietf-imapapnd-ap… Adrien de Croy
- Re: [imapext] AD review of draft-ietf-imapapnd-ap… Arnt Gulbrandsen
- Re: [imapext] AD review of draft-ietf-imapapnd-ap… Dave Cridland
- Re: [imapext] AD review of draft-ietf-imapapnd-ap… Dave Cridland
- Re: [imapext] AD review of draft-ietf-imapapnd-ap… Arnt Gulbrandsen
- Re: [imapext] AD review of draft-ietf-imapapnd-ap… Alexey Melnikov
- Re: [imapext] AD review of draft-ietf-imapapnd-ap… Alexey Melnikov
- Re: [imapext] AD review of draft-ietf-imapapnd-ap… Alexey Melnikov
- Re: [imapext] AD review of draft-ietf-imapapnd-ap… Alexey Melnikov
- Re: [imapext] AD review of draft-ietf-imapapnd-ap… Adrien de Croy
- Re: [imapext] AD review of draft-ietf-imapapnd-ap… Adrien de Croy
- Re: [imapext] AD review of draft-ietf-imapapnd-ap… Alexey Melnikov
- Re: [imapext] AD review of draft-ietf-imapapnd-ap… Alexey Melnikov
- Re: [imapext] AD review of draft-ietf-imapapnd-ap… Jayantheesh S B
- Re: [imapext] AD review of draft-ietf-imapapnd-ap… Jayantheesh S B
- Re: [imapext] AD review of draft-ietf-imapapnd-ap… Barry Leiba
- Re: [imapext] AD review of draft-ietf-imapapnd-ap… Bron Gondwana
- Re: [imapext] AD review of draft-ietf-imapapnd-ap… Barry Leiba
- Re: [imapext] AD review of draft-ietf-imapapnd-ap… Adrien de Croy
- Re: [imapext] AD review of draft-ietf-imapapnd-ap… Alexey Melnikov
- Re: [imapext] AD review of draft-ietf-imapapnd-ap… Narendra Bisht
- Re: [imapext] AD review draft-ietf-imapapnd-appen… Alexey Melnikov
- Re: [imapext] AD review of draft-ietf-imapapnd-ap… Barry Leiba
- Re: [imapext] AD review draft-ietf-imapapnd-appen… Stu Brandt
- Re: [imapext] AD review of draft-ietf-imapapnd-ap… Alexey Melnikov
- Re: [imapext] AD review draft-ietf-imapapnd-appen… Alexey Melnikov
- Re: [imapext] AD review of draft-ietf-imapapnd-ap… Jayantheesh S B
- Re: [imapext] AD review draft-ietf-imapapnd-appen… S Moonesamy
- Re: [imapext] AD review of draft-ietf-imapapnd-ap… Barry Leiba
- Re: [imapext] AD review of draft-ietf-imapapnd-ap… Jayantheesh S B
- Re: [imapext] AD review of draft-ietf-imapapnd-ap… Jayantheesh S B
- Re: [imapext] AD review of draft-ietf-imapapnd-ap… Adrien de Croy
- Re: [imapext] AD review of draft-ietf-imapapnd-ap… Barry Leiba
- Re: [imapext] AD review of draft-ietf-imapapnd-ap… Jayantheesh S B
- Re: [imapext] AD review draft-ietf-imapapnd-appen… Dave Cridland
- Re: [imapext] AD review of draft-ietf-imapapnd-ap… Alexey Melnikov
- Re: [imapext] AD review draft-ietf-imapapnd-appen… Alexey Melnikov
- Re: [imapext] AD review of draft-ietf-imapapnd-ap… Jayantheesh S B
- Re: [imapext] AD review of draft-ietf-imapapnd-ap… Barry Leiba