Re: [imapext] Kathleen Moriarty's No Objection on draft-ietf-imapapnd-appendlimit-extension-08: (with COMMENT)

Barry Leiba <barryleiba@computer.org> Wed, 06 January 2016 22:39 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 A8D5B1A1B2C; Wed, 6 Jan 2016 14:39:20 -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 LhkuzJ4PQG_p; Wed, 6 Jan 2016 14:39:19 -0800 (PST)
Received: from mail-ig0-x229.google.com (mail-ig0-x229.google.com [IPv6:2607:f8b0:4001:c05::229]) (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 2A4B31A1B2B; Wed, 6 Jan 2016 14:39:19 -0800 (PST)
Received: by mail-ig0-x229.google.com with SMTP id mw1so42308906igb.1; Wed, 06 Jan 2016 14:39:19 -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=caHIueDtcigkWDwUORcsMSjungipke3mr5U+qRLtwbc=; b=N1az4f6QA8Ip8lACwADR0XuH/mIkZIToWBr92ZOTkhzHqp9wAeg6tyW2BQqrFAm6tb rI4kME/iAmJUCGjTtug+VnGq5kJoww5w8GHDlgsJwmvBhocXlBebUvAWeIQU0jFQ7iYx U+VIBRS/GjUDx8g6GH0bnJtmXE9qPNt73QhmInFMKAeyZgLjdxPGGKRpzPDTsKJRxeFe wiOvdDMeBcqTXXtV3CEv3FykXR7FleM3FduHfXgcOnZKiyyba1vH7pSynxNrCXaS4NaO b9psscUWaM9fWNqOWC091/2Gwu0oZzR7loHOIjZ7SAT6BA4fj7DbCvi/aTdHcOBvjC14 Yuug==
MIME-Version: 1.0
X-Received: by 10.50.32.9 with SMTP id e9mr12508653igi.53.1452119958491; Wed, 06 Jan 2016 14:39:18 -0800 (PST)
Sender: barryleiba@gmail.com
Received: by 10.36.117.83 with HTTP; Wed, 6 Jan 2016 14:39:18 -0800 (PST)
In-Reply-To: <F8822335-25E8-4A5A-A13C-05E9F16068B3@gmail.com>
References: <20160106012803.29192.54119.idtracker@ietfa.amsl.com> <CALaySJLo3o7j2qJNxrLaGKntHhURme=tTy5vCPM9sDR7NU4hVg@mail.gmail.com> <CAHbuEH6kMq2bQkCvWuY3pd8-81xt3VGfN4YoPV7cVhf1VehzoA@mail.gmail.com> <CALaySJJeNHOLM2q9tixVBGzgmVcbwbugJ73-vZ-QyNyUCXzNmw@mail.gmail.com> <F8822335-25E8-4A5A-A13C-05E9F16068B3@gmail.com>
Date: Thu, 07 Jan 2016 06:39:18 +0800
X-Google-Sender-Auth: P3lW5DmUmzsWlfLyFSYUiT7h27w
Message-ID: <CALaySJ+cH_v0fdO9dFwxgNZt71AcoBdQssJhb0NbOZvWB4EVJA@mail.gmail.com>
From: Barry Leiba <barryleiba@computer.org>
To: Kathleen Moriarty <kathleen.moriarty.ietf@gmail.com>
Content-Type: text/plain; charset="UTF-8"
Archived-At: <http://mailarchive.ietf.org/arch/msg/imapext/M6gHHsqz8JwPaA8beyRTliPoj5Q>
Cc: "draft-ietf-imapapnd-appendlimit-extension@ietf.org" <draft-ietf-imapapnd-appendlimit-extension@ietf.org>, "imapapnd-chairs@ietf.org" <imapapnd-chairs@ietf.org>, SM <sm+ietf@elandsys.com>, "imapext@ietf.org" <imapext@ietf.org>, The IESG <iesg@ietf.org>
Subject: Re: [imapext] Kathleen Moriarty's No Objection on draft-ietf-imapapnd-appendlimit-extension-08: (with COMMENT)
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: Wed, 06 Jan 2016 22:39:20 -0000

>>> "But with this extension, the attacker can immediately choose a value
>>> that's a little too large,"
>>>
>>> It doesn't read well to me.  Why would they chose a value that's a
>>> little too large?  Too large for what?  They already have the size
>>> limit per server or per mailbox.  Does this mean they will send a
>>> bunch of messages with the append size maxed out for the mailbox or
>>> the server to fill the quota?
>>
>> The point of the attack isn't filling a mailbox; it's sending
>> boatloads of data to the server.  Suppose there's a limit of 2 MB.  If
>> the client sends 2 MB messages repeatedly, those messages will
>> eventually cause the mailbox to hit the quota, and further attempts to
>> bombard the server will be rejected.  But messages that are, say,
>> 2.1MB will fail to append (the server will respond "NO" to them), and
>> the client can keep bombarding the server with such messages.  The
>> text is trying to warn about that, suggesting that the server might
>> "take a hard line" -- that is, take more serious action than just
>> saying "NO" to the append attempts, but perhaps actually lock out the
>> account until someone checks out the situation.
>
> This point wasn't clear to me from the current text.  I'd suggest updating it to make it more clear.

I think it is, so please suggest specific text that you think will
help clarify it for you.

>>> Why isn't it explicit in that such messages should/MUST be rejected?
>>
>> The messages themselves will be rejected (they APPEND command will get
>> "NO" for a response), but the damage -- the sending of a lot of data
>> unnecessarily -- will have already been done.
>
> Can this be made more clear as well?  It's not in the current text.

No, it's not, because it's how IMAP works.  This really isn't
something we need to make clear here: anyone implementing this already
knows this and will already be doing it.  This is only about
advertising an APPEND limit, not about how APPEND works and how you
say "NO" to an APPEND command.

Barry