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

Barry Leiba <barryleiba@computer.org> Thu, 17 December 2015 23:21 UTC

Return-Path: <barryleiba@gmail.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 2BCDF1B311D for <imapext@ietfa.amsl.com>; Thu, 17 Dec 2015 15:21:01 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.278
X-Spam-Level:
X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] 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 0p5trDY22eBJ for <imapext@ietfa.amsl.com>; Thu, 17 Dec 2015 15:21:00 -0800 (PST)
Received: from mail-vk0-x231.google.com (mail-vk0-x231.google.com [IPv6:2607:f8b0:400c:c05::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F11361B3117 for <imapext@ietf.org>; Thu, 17 Dec 2015 15:20:59 -0800 (PST)
Received: by mail-vk0-x231.google.com with SMTP id a189so55912407vkh.2 for <imapext@ietf.org>; Thu, 17 Dec 2015 15:20:59 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=miMJ02XM3I++iMg8tmdu8h9vb6AclZT14UD86metEPc=; b=fPbVrQQlDWB64uNZD/YKax2WmZmngtLsfyTykTIlwlzHXeXUyXkbYUM9iHdISB3IkH kk9aJJpuglHUZ/f7yS9CoWj1Mp/mG4wiYD9472gR3WPyIwMcpggejznPBdEGWDMnH3VH 2navwMSi+kfj2KL5QJQTd91gPaH2tt76Qrx+F3/3G8v22GSJXCtcEPgobvY4auQr2trl DLthPiQ+9hvc5L8bTqE+ohIgwA08NR+jlI065JX37cRbh4uGVhrvMWbDKVURUnQNQK6u k/Rs9eXQyrGxMaNBPmatWopIGg1Czu+h2jMZqPQ7GqSyO6uYadYdg9WdRNraq0LrWfpc s4yA==
MIME-Version: 1.0
X-Received: by 10.31.140.199 with SMTP id o190mr273876vkd.63.1450394459010; Thu, 17 Dec 2015 15:20:59 -0800 (PST)
Sender: barryleiba@gmail.com
Received: by 10.31.182.211 with HTTP; Thu, 17 Dec 2015 15:20:58 -0800 (PST)
In-Reply-To: <4c5100ed28d442ad89a5a25028d10c8f@SEAMBX01.sea.samsung.com>
References: <emcf7f771e-a84b-4df3-b9ff-06dd5417a655@bodybag> <5A5084CC-6733-45DB-B3D5-4F73285257D0@isode.com> <6679218db47f443794b1ce28452623eb@SEAMBX07.sea.samsung.com> <CAC4RtVDnirH1n1hjtLPpMAEYgBmdYmsQxo3WiXiErEFQYPP8gg@mail.gmail.com> <0d5eee161a1e4e2ab78ea4696e6fa17e@SEAMBX01.sea.samsung.com> <CALaySJKURA5gPatPeddXj1twtjqZNh_j-G03JDEQZap38VbS1w@mail.gmail.com> <4c5100ed28d442ad89a5a25028d10c8f@SEAMBX01.sea.samsung.com>
Date: Thu, 17 Dec 2015 18:20:58 -0500
X-Google-Sender-Auth: skz8uxwKO7jxitML0wo_kW-TDIw
Message-ID: <CALaySJLBkPfYc6mJzWV4wd9EhXq_h_i6umhUsZJEbcCW4ftPkw@mail.gmail.com>
From: Barry Leiba <barryleiba@computer.org>
To: Jayantheesh S B <j.sb@sea.samsung.com>
Content-Type: text/plain; charset="UTF-8"
Archived-At: <http://mailarchive.ietf.org/arch/msg/imapext/qekxehJ5A_-aKL8MxZ_pyNUX37U>
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
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:21:01 -0000

> 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.

OK, I see the point now.  It seems a little thin (but, then, the
document does already say it is) -- I can just try to append 300MB,
using non-synch literal, right from the start.

But perhaps this will be more satisfying:

OLD
   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.
NEW
   The IMAP APPENDLIMIT extension described in this document can
   conceivably be used to facilitate Denial-of-Service attacks by allowing
   an attacker to home in on a critical value right away.  The attacker
   might want to send a large data block to the server repeatedly,
   forcing the server to process the block, but would not want to limit
   the scope of its attack by filling an actual mailbox with successful
   appends.  Without this extension, the attacker needs to guess: a
   too-small guess results in an appended message that takes up the
   user's quota, while a far-too-large guess might simply cause the
   server to terminate the connection because of suspected abuse.

   But with this extension, the attacker can immediately choose a
   value that's a little too large, but not so much as to trigger an "abuse"
   response, making it easier to mount such an attack.

   To mitigate this extension's input to such an attack, a server might
   take a harder line on message sizes that are above the APPENDLIMIT
   value -- because the client knows the limit and should not even be
   trying to send such commands, a server might consider even a single
   attempt to be abusive, and terminate the IMAP connection straight
   away.
END

How's that work for you?

Barry