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

From: "Kathleen Moriarty" <[email-masked]>
Date: Tue, 05 Jan 2016 17:28:03 -0800

Kathleen Moriarty has entered the following ballot position for
draft-ietf-imapapnd-appendlimit-extension-08: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-imapapnd-appendlimit-extension/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Thanks for your work on this extension, it seems useful, I just have a
few comments that can be left to the editors and AD to handle if I
disappear for maternity leave.  

I think the security considerations section could be a bit more clear on
the actual risks with this extension.  I think the flow of the section
can be improved to make these risks a bit more clear.

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'm not sure why there is a focus on "without this extension".

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?

---

From: Barry Leiba <[email-masked]>
Date: Wed, 6 Jan 2016 11:55:00 +0800

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

> 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

---

From: Kathleen Moriarty <[email-masked]>
Date: Tue, 5 Jan 2016 23:06:17 -0500

Hi Barry,

> of the user it's logged in as.

Yes, I understand that.

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

> 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

-- 

Best regards,
Kathleen

---

From: Barry Leiba <[email-masked]>
Date: Wed, 6 Jan 2016 13:08:30 +0800

> and on a per mailbox basis.  This also comes up in the security

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 section doesn't read well IMO.

That's entirely possible.

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

> 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

---

From: Kathleen Moriarty <[email-masked]>
Date: Wed, 6 Jan 2016 07:57:45 -0500

Sent from my iPhone

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

> unnecessarily -- will have already been done.

Can this be made more clear as well?  It's not in the current text.

> overruns are not an issue here, and this extension does nothing 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

---

From: S Moonesamy <[email-masked]>
Date: Wed, 06 Jan 2016 12:30:43 -0800

Hi Jay, Naren,
>Can this be made more clear as well?  It's not in the current text.

Could you please suggest some text to address the above?

Regards,
S. Moonesamy (as document shepherd)

---

From: Barry Leiba <[email-masked]>
Date: Thu, 7 Jan 2016 06:39:18 +0800

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

> 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

---

From: Kathleen Moriarty <[email-masked]>
Date: Wed, 6 Jan 2016 18:47:14 -0500

> I think it is, so please suggest specific text that you think will

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.

> 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

-- 

Best regards,
Kathleen

---

From: Barry Leiba <[email-masked]>
Date: Thu, 7 Jan 2016 08:49:03 +0800

Hm.  From your response, I'm still not sure you understand the issue
we're bringing up in the Security Considerations, so I'd still like to
push on the discussion a bit (even though it's "only" a comment) to
make sure we do get the point across properly.

The Security Considerations text is not talking about rejecting APPEND
commands.  For servers that have limits, there are already limits, and
they already reject APPENDs that are above their limits.  That's not
an issue.

The resource consumption issue has to do with the way the IMAP APPEND
command works.  What I'm going to say here is part of IMAP, and
doesn't belong in this document, but the background might help you for
this discussion.  For a normal IMAP APPEND, the client sends "APPEND
MailboxName {27183}" to say that it wants to append a message to
MailboxName and that the message is 27,183 bytes long.  It waits for a
server response.  If the server responds "OK", the client then sends
the 27,183 bytes and processing continues.  The server will respond
"OK" again when everything's done.  If the server responds "NO" after
the length is sent, the client knows that it should not send the
message data because the append has already been denied.

There's an extension called non-synchronizing literals (LITERAL+),
which allows the client to instead send "APPEND MailboxName
{+27183}This is the message data[...]End of message data." (where
that's actually 27,183 bytes of message data).  The server will then
process the APPEND command and can still respond OK or NO... but the
data has been sent already, taking up resources, even though it might
not have been needed (the server would have responded "NO" to the
initial synchronizing literal if it had been given the chance).

So the resource consumption problem has to do with non-synchronizing
literals.  This extension is meant to help with that problem by
allowing servers to advertise append limits so that cooperative
clients can avoid sending message data that will only get a NO
response in the end.

The issue that's being brought up in the Security Considerations is a
possible (albeit far fetched) situation wherein a rogue client uses
this new information to tune its attack by making appends that it
knows will fail, and it knows that because of the advertised limit.
And it's specifically intended to send useless data to the server.  It
knows the APPEND commands will ultimately be rejected, and it wants
them to be -- the point is simply to send useless data.

So no text that explains about rejecting (responding "NO" to) APPEND
commands will help here.  What we're trying to say is that servers
should watch for behaviour they consider abusive and "take a harder
line" with respect to clients that appear abusive, in order to try to
avoid these sorts of attacks.

Given that explanation, do you have a suggestion for re-wording things
to make it clearer (without including explanations of how IMAP APPEND
commands, IMAP responses, and IMAP literals work)?

Barry

---

From: Kathleen Moriarty <[email-masked]>
Date: Wed, 6 Jan 2016 20:32:52 -0500

> commands, IMAP responses, and IMAP literals work)?

I was just suggesting that you could cut out the scenario, leave the
last sentence and say it's because of a possible attack on resources,
'resources' being a short way of describing the scenario laid out.  If
some other attack comes out that is mitigated in a similar way that
uses 'resources' in another way, you are covered.  It also gets rid of
the extra text that I don't see as necessary.  But leave it if you
think it's fine.

Thanks,
Kathleen

-- 

Best regards,
Kathleen

---

From: Barry Leiba <[email-masked]>
Date: Fri, 8 Jan 2016 08:30:44 +0800

Authors and working group:
In light of this discussion, I suggest that we replace the content of
the Security Considerations section with this:

NEW
   This extension provides additional information that cooperative
   clients can use as an optimization, and does not introduce new
   security concerns.  This extension does not address abusive clients
   that intend to consume server resources, and servers will still have
   to take action to disconnect and/or restrict access to clients that
   exhibit abusive behavior.
END

Please comment, and if there are no objections, please make the change
in another revision.  Thanks.

Barry

---

From: Jayantheesh S B <[email-masked]>
Date: Fri, 8 Jan 2016 16:05:51 +0000

Hi Barry,

We are fine with the proposed text. We will update the draft with this text and release a new version (10). 

Regards,
Jay
-----Original Message-----
From: imapext [mailto:[email-masked]] On Behalf Of Barry Leiba
Sent: Thursday, January 07, 2016 7:31 PM
To: [email-masked]; [email-masked]
Cc: [email-masked]; The IESG; SM
Subject: Re: [imapext] Kathleen Moriarty's No Objection on draft-ietf-imapapnd-appendlimit-extension-08: (with COMMENT)

Authors and working group:
In light of this discussion, I suggest that we replace the content of the Security Considerations section with this:

NEW

Please comment, and if there are no objections, please make the change in another revision.  Thanks.

Barry

> the extra text that I don't see as necessary.  But leave it if you 

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

---

From: Barry Leiba <[email-masked]>
Date: Sat, 9 Jan 2016 17:27:04 -0500

> text and release a new version (10).

Great; thanks.  I'd like to hear from a couple of others to make sure
it's OK with a few more people.  Alexey, SM, can the two of you weigh
in?

Barry

---

From: Alexey Melnikov <[email-masked]>
Date: Sun, 10 Jan 2016 13:00:07 +0000

Hi Barry,

> it's OK with a few more people.  Alexey, SM, can the two of you weigh

Changes in -09 and -10 look good to me.

---

From: S Moonesamy <[email-masked]>
Date: Sun, 10 Jan 2016 07:45:33 -0800

Hi Barry,
>it's OK with a few more people.  Alexey, SM, can the two of you weigh

The first sentence in Section 6 
(draft-ietf-imapapnd-appendlimit-extension-10) mentions that the 
extention does not introduce new security concerns.  The second 
sentence is about  clients which exhibit abusive behaviour.

The text looks fine.

Regards,
S. Moonesamy

---

From: Barry Leiba <[email-masked]>
Date: Sun, 10 Jan 2016 12:18:38 -0500

> (draft-ietf-imapapnd-appendlimit-extension-10) mentions that the extention
> does not introduce new security concerns.  The second sentence is about
> clients which exhibit abusive behaviour.

Yes: the first sentence says that this extension is about cooperative
clients.  The second sentence says that it does nothing with respect
to abusive clients, and that servers still have to deal with that.
Are you saying that you think that's unclear and needs a few more
words?

> The text looks fine.

Kewl.

b

---

From: S Moonesamy <[email-masked]>
Date: Sun, 10 Jan 2016 09:23:48 -0800

Hi Barry,
>Are you saying that you think that's unclear and needs a few more

Sorry, I should have been clear.  I explained what I understood on 
reading the text and concluded that it is fine.  I don't think that 
more words are needed.

Regards,
S. Moonesamy

---

From: S Moonesamy <[email-masked]>
Date: Sun, 10 Jan 2016 09:23:48 -0800

Hi Barry,

Regards,
S. Moonesamy