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

[Barry Leiba <[e-mail]>]

Hm.  From your response, I'm still not sure you understand the issue
we're bringing up in the Security Considerations, so I'd still like to
push on the discussion a bit (even though it's "only" a comment) to
make sure we do get the point across properly.

The Security Considerations text is not talking about rejecting APPEND
commands.  For servers that have limits, there are already limits, and
they already reject APPENDs that are above their limits.  That's not
an issue.

The resource consumption issue has to do with the way the IMAP APPEND
command works.  What I'm going to say here is part of IMAP, and
doesn't belong in this document, but the background might help you for
this discussion.  For a normal IMAP APPEND, the client sends "APPEND
MailboxName {27183}" to say that it wants to append a message to
MailboxName and that the message is 27,183 bytes long.  It waits for a
server response.  If the server responds "OK", the client then sends
the 27,183 bytes and processing continues.  The server will respond
"OK" again when everything's done.  If the server responds "NO" after
the length is sent, the client knows that it should not send the
message data because the append has already been denied.

There's an extension called non-synchronizing literals (LITERAL+),
which allows the client to instead send "APPEND MailboxName
{+27183}This is the message data[...]End of message data." (where
that's actually 27,183 bytes of message data).  The server will then
process the APPEND command and can still respond OK or NO... but the
data has been sent already, taking up resources, even though it might
not have been needed (the server would have responded "NO" to the
initial synchronizing literal if it had been given the chance).

So the resource consumption problem has to do with non-synchronizing
literals.  This extension is meant to help with that problem by
allowing servers to advertise append limits so that cooperative
clients can avoid sending message data that will only get a NO
response in the end.

The issue that's being brought up in the Security Considerations is a
possible (albeit far fetched) situation wherein a rogue client uses
this new information to tune its attack by making appends that it
knows will fail, and it knows that because of the advertised limit.
And it's specifically intended to send useless data to the server.  It
knows the APPEND commands will ultimately be rejected, and it wants
them to be -- the point is simply to send useless data.

So no text that explains about rejecting (responding "NO" to) APPEND
commands will help here.  What we're trying to say is that servers
should watch for behaviour they consider abusive and "take a harder
line" with respect to clients that appear abusive, in order to try to
avoid these sorts of attacks.

Given that explanation, do you have a suggestion for re-wording things
to make it clearer (without including explanations of how IMAP APPEND
commands, IMAP responses, and IMAP literals work)?

Barry



On Thu, Jan 7, 2016 at 7:47 AM, Kathleen Moriarty
<[e-mail]> wrote:
> On Wed, Jan 6, 2016 at 5:39 PM, Barry Leiba <[e-mail]> wrote:
>>>>> "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.
>
> If we go back to my original comment, the last one:
>
> "Then, it's a common security programming practice to enforce size
> limitations in code.  Why is there a focus on an attacker sending
> append content that exceeds the allowable size rather than just saying
> that such append content should be rejected?"
>
> This gets at the crux of the text in the security considerations
> section.  This is essentially what's recommended, but take a round
> about way to get to this recommendation.  Exceeding the allowed sizes
> is not permitted to prevent this 'attack'.
>
> You can leave it as-is, but I think the text can be more clear by
> eliminating most of the introduction to the actual recommendation.
>
>
>>
>>>>> 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, my comments are about that limit and I think drafts should be
> readable by more than just those who implement mail (in this case).
> The last sentences of the security considerations section contains the
> same point I am making, but it takes a while to get to that
> recommendation, so I'm not really sure why you are arguing this point
> and thinking I am talking about anything other than the APPEND limit.
>
> It says:
>
> " 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."
>
> The whole section could be reduced by starting with this
> recommendation and just stating that it prevents attacks on resources
> by rejecting messages with sizes above the append limit.  There may be
> other attacks that are guarded against with this recommendation as
> well, so why limit it to this specific example and why lead with the
> example.  I think it's more straightforward to just have the
> recommendation and that it is to prevent attacks on resources.
>
> If you don't want to fix it, that's fine.  It's just a comment.
>
> Kathleen
>
>>
>> Barry
>
>
>
> --
>
> Best regards,
> Kathleen
>