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

[Kathleen Moriarty <[e-mail]>]

On Wed, Jan 6, 2016 at 7:49 PM, Barry Leiba <[e-mail]> wrote:
> 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)?

I was just suggesting that you could cut out the scenario, leave the
last sentence and say it's because of a possible attack on resources,
'resources' being a short way of describing the scenario laid out.  If
some other attack comes out that is mitigated in a similar way that
uses 'resources' in another way, you are covered.  It also gets rid of
the extra text that I don't see as necessary.  But leave it if you
think it's fine.

Thanks,
Kathleen

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



-- 

Best regards,
Kathleen