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