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

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

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.

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?

> 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

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