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

[Kathleen Moriarty <[e-mail]>]

Sent from my iPhone

On Jan 6, 2016, at 12:08 AM, Barry Leiba <[e-mail]> wrote:

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

This point wasn't clear to me from the current text.  I'd suggest updating it to make it more clear.

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

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

Ok, thanks.  I think of the other text is clear, then this concern won't come up as it would be understood as not being an issue.

Thanks,
Kathleen 

> 
> Barry