Re: [imapext] AD review of draft-ietf-imapapnd-appendlimit-extension-06

[Alexey Melnikov <[e-mail]>]

On 10/12/2015 23:53, Adrien de Croy wrote:
> One thing I'm not clear on.
>
> Is this supposed really to limit the max message size, or just really 
> APPEND?
Just APPEND.
> For example would COPY or MOVE trigger this?
No. In order to express that limit, there is the QUOTA extension.
> If it's really a max size of a message in a folder, it should also 
> apply to COPY and MOVE.
>
> And I'd suggest that having a different limit in different folders 
> will result in some nasty support calls.
>
> Adrien
>
>
> ------ Original Message ------
> From: "Barry Leiba" <[e-mail]>
> To: "Narendra Bisht" <[e-mail]>; "Adrien de Croy" 
> <[e-mail]>
> Cc: "[e-mail]" 
> <[e-mail]>; 
> "[e-mail]" <[e-mail]>
> Sent: 11/12/2015 8:10:28 a.m.
> Subject: Re: [imapext] AD review of 
> draft-ietf-imapapnd-appendlimit-extension-06
>
>> Hi, Narendra, and thanks for the responses.  I'm eliminating all the
>> things we're in agreement on, so we can discuss the others a bit.
>>
>>>  The substantive issue is this:  Suppose my server supports
>>>  APPENDLIMIT, and wants to advertise that to the client, but there's no
>>>  global limit.  So it says "APPENDLIMIT" in response to CAPABILITY,
>>>  without giving a number.  Good.  Now you're requiring that there be a
>>>  limit on every mailbox -- the protocol provides no way to tell the
>>>  client that there's no limit on this mailbox.  Why is that not a
>>>  problem?
>>>
>>>  [Naren] This draft is to publish the APPENDLIMIT, if there is any. If
>>>  you accept any size then there is no need to publish this policy.
>>
>> I think you missed my point.
>>
>> The situation I'm talking about is this:
>>
>> - The server has no global limit, so no number is advertised on the
>> CAPABILITY response.  The spec says, therefore, that per-mailbox
>> limits have to be advertised on, say, STATUS commands.  Fine.
>>
>> - There's a limit of, say, 50,000 for INBOX.  So when I do STATUS
>> INBOX (APPENDLIMIT), the server responds with "* STATUS INBOX
>> (APPENDLIMIT 50000)".  Fine.
>>
>> - But there's no limit on the "Stuff-to-save" mailbox.  No limit at all.
>>
>> How does the server respond when I do "STATUS Stuff-to-save
>> (APPENDLIMIT)" ?  Why is it not a problem that the spec doesn't answer
>> this question?
>>
>>>  -- Section 2 --
>>>
>>>  "An IMAP server that supports APPENDLIMIT extension advertises this by
>>>   including the name APPENDLIMIT in its capability list. IMAP server
>>>   MAY advertise this capability after user has logged in."
>>>
>>>  This says nothing about whether the server is allowed to advertise the
>>>  capability before the user has logged in.  I also don't think this is
>>>  an appropriate use of 2119 "MAY".  If you mean, "The IMAP server MUST
>>>  NOT advertise this capability until after the user has logged in,"
>>>  then you should say it that way.  (And if that's not what you mean,
>>>  please discuss it with me and clarify.)
>>>  >
>>>  [Naren] We purposefully marked it as a MAY, because it alerts
>>>  implementations to the possibility, but doesn't have any effect in
>>>  interoperability.
>>>
>>>  What we mean here is client should be ready to handle this no matter
>>>  when the capability is sent.
>>
>> Great, and I saw the discussion in the other thread.  My sense here is
>> that 2119 key words aren't appropriate for this at all: there's no
>> choice here that needs a "MAY" -- you're just talking about how the
>> protocol works when this option is in effect:
>>
>> NEW
>> An IMAP server that supports APPENDLIMIT extension advertises this by
>> including the name APPENDLIMIT in its capability list in Authenticated
>> state.  The server may also advertise this extension before the user has
>> logged in.
>> END
>>
>> (With this formulation, if you really want to say "MAY" in the last
>> sentence, I won't object further.
>>
>>>  -- Section 4 --
>>>
>>>  "Client can avoid use of LITERAL+ [RFC2088], when maximum upload size
>>>   supported by the IMAP server is unknown."
>>>
>>>  What?
>>>  Don't you mean "The client SHOULD avoid"?  I'd even use this as an 
>>> opportunity
>>>  to make it firmer, and say "The client MUST avoid".  No?
>>>  If not, why not?
>>>
>>>   [Naren] We will change it to a MUST
>>
>> Hold off on this, because there's still discussion based on Adrian's
>> message in another thread... which I'll bring back here:
>>
>> On Tue, Dec 8, 2015 at 4:31 PM, Adrien de Croy <[e-mail]> wrote:
>>>
>>>  The proposal that a client MUST avoid LITERAL+/NSLs presumes there 
>>> is a
>>>  limit when in fact there may actually not be one.  Of course there 
>>> is always
>>>  a finite limit, but there may be no policy limit.  In fact we don't 
>>> plan to
>>>  implement the limit as we've never had a request for it and don't 
>>> see a need
>>>  to deny authenticated users from appending a mail (and see some 
>>> dangers in
>>>  that).
>>>
>>>  I think MAY works in that it proposes a strategy, and doesn't 
>>> confuse issues
>>>  with servers that already implement LITERAL+ but not a limit.  
>>> Otherwise you
>>>  may be placing a new requirement on old software to police the new 
>>> MUST, or
>>>  implementing the limit places addition requirements to alter 
>>> behaviour of
>>>  LITERAL+ support to enforce this which IMO over-complicates it.
>>
>> But the point of the use of LITERAL+ with APPEND isn't just about this
>> spec and overall limits -- it's about whether we should use LITERAL+
>> with APPEND *at all*.  There are other reasons that any particular
>> APPEND might fail, and one point of using literals (and *never*
>> allowing quoted strings, for example) is exactly to give the server a
>> chance to say "NO" to the APPEND *before* the message data is shipped
>> over.  Using LITERAL+ for APPEND data violates that.
>>
>> It was always the intent of LITERAL+ that it be used as a way to
>> eliminate the extra round trip on short strings, where the OK from the
>> server isn't necessary -- such as for username and password at login,
>> or for mailbox names in various places (including the mailbox name in
>> an APPEND command.
>>
>> My point here is that we now have an opportunity to stress this: that
>> it's not a generally good idea to use LITERAL+ for the message data in
>> an APPEND command, because it doesn't give the server the opportunity
>> to say, "OK, yes, go ahead and send me the message."
>>
>> I'm absolutely willing to accept that "MUST NOT" use LITERAL+ for that
>> is too strong.  But I'm still going to hold out for "SHOULD NOT", and
>> would like to continue the discussion of why you disapprove.
>>
>>>  "STATUS APPENDLIMIT is considered to be fast"
>>>
>>>  What does that mean?
>>>  Is this meant to be advice to the server, to make sure that it *is* 
>>> fast?  If so, then
>>>  say it more that way.  If not, then please tell me what it's 
>>> supposed to mean.
>>>
>>>  [Naren] It's not an advice to the server, we are trying to convey 
>>> that this approach
>>>  is considered to be faster than evaluating the remaining quota for 
>>> a mailbox.
>>
>> "Is considered to be" is not useful specification language.  If you
>> want this to affect what clients or servers do, you should word this
>> in terms that more specifically tell them what you want them to do.
>> Please come up with a better way to say what you really mean here.
>>
>> Let me take a stab, and you can see if this has the right sense (edit
>> as appropriate, of course):
>>
>> OLD
>>    STATUS APPENDLIMIT is considered to be fast and there is no need to
>>    evaluate remaining quotas (if any) when returning APPENDLIMIT values.
>>    APPEND can still fail due to ACL and quota related issues, even if 
>> the
>>    message being appended is smaller than the APPENDLIMIT.
>>
>> NEW
>>    Computing the APPENDLIMIT should be fast, and need not take ACLs,
>>    quotas, and other such information into account.  The APPENDLIMIT
>>    specifies one part of the policy, but an APPEND command can still 
>> fail
>>    due to issues related to ACLs and quotas issues, even if the message
>>    being appended is smaller than the APPENDLIMIT.
>>
>> END
>>
>> Also, why is this in Section 4, rather than in, say, a Section 3.3?
>> It has nothing to do with the APPEND response, which is the subject of
>> Section 4.
>>
>>>  -- Section 6 --
>>>
>>>  "The IMAP APPENDLIMIT extension described in this document can
>>>   conceivably be used to facilitate Denial-of-Service attacks.
>>>   Specifically, the information contained in the APPENDLIMIT capability
>>>   and use of the APPEND command make it somewhat quicker and easier to
>>>   devise an efficacious Denial-of-Service attack."
>>>
>>>  What?  How? If it's true (it might be, but you haven't said), then you
>>>  should explain it.
>>>
>>>  [Naren] What we meant here is that using this extension it will easy
>>>  and quicker to get the upload limit and using that limit against the
>>>  server.
>>
>> Why?  I don't understand why that helps anyone mount an attack. And
>> in any case, it needs to be explained here in the document.
>>
>> And you didn't respond to these questions in my review:
>>
>>>  "In addition, no
>>>   issues are addressed involving trusted systems and possible 
>>> release  of information via the mechanisms described in this document."
>>>
>>>  What does this mean, and why is it here?
>>>
>>>  "IMAP APPENDLIMIT extension doesn't add any new security 
>>> considerations  that are not already present in the base IMAP 
>>> protocol [RFC3501]."
>>>
>>>  Doesn't the presence of the first paragraph belie that?
>>
>> Barry
>
> _______________________________________________
> imapext mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/imapext