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

Hi Barry,


On Tue, Jan 5, 2016 at 10:55 PM, Barry Leiba <[email protected]> wrote:
>> First, this extension lets you find out the limit for either the server
>> or individual mailboxes, so shouldn't the first part of the description
>> focus on a possible DoS filling up those resources?
>
> I don't understand where you're going with this.  This has nothing to
> do with a storage limit -- that's handled by the QUOTA extension
> that's a separate thing, and any client can already fill up the quota
> of the user it's logged in as.

Yes, I understand that.

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

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

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?

Then with the sentence:

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

Why isn't it explicit in that such messages should/MUST be rejected?
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).

Thanks,
Kathleen

>
>> 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?
>
> A server will always have to be able to deal (in code) with messages
> greater than the maximum size they allow, because IMAP syntactically
> allows them to be transmitted.  The server can only say "NO" to
> appending the message after it receives it.  The security
> considerations are talking about whether the server might do something
> harsher to a client that appears to be abusive -- kicking it off and
> disabling the account, for example.
>
> Barry



-- 

Best regards,
Kathleen

_______________________________________________
imapext mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/imapext