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

[Barry Leiba <[e-mail]>]

>> This extension is about limiting the size of a single message, because
>> servers have such limitations and currently have no way to tell the
>> client about them.  The only purpose of this extension is to let a
>> client discover a server's size limit for a single message.
>
> In section 3, it also discusses per mailbox limitations.  The draft
> covers both the option for this extension being used for the server
> and on a per mailbox basis.  This also comes up in the security
> considerations section.

Server-wide limits and per-mailbox limits are no different with regard
to any security considerations.  I don't see where the Security
Considerations section says that they are.  Can you point to specific
text?

>> The security considerations need to be about how that knowledge can be
>> used to breach security.  The answer to that is "it can't, really",
>> but the one issue we came up with is documented there.
>>
>> Do you have any specific security considerations to suggest that are
>> specific to this extension: the ability for a client to discover what
>> a server's policy limit is on the size of a single message?
>
> The security considerations section doesn't read well IMO.

That's entirely possible.

> When it gets to the following sentence:
>
> "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.

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

> For the security consideration, this seems like an expected response
> to prevent additional problems (checking that size limitations are met
> to avoid buffer overrun scenarios in code).

This has nothing to do with buffer overruns.  Servers already have to
deal with arbitrary sizes for literals, and they will already allocate
buffers based on the literal size that the client sends.  Buffer
overruns are not an issue here, and this extension does nothing that
changes that.

Barry