Re: [imapext] AD review of draft-ietf-imapapnd-appendlimit-extension-06
Barry Leiba <barryleiba@computer.org> Thu, 10 December 2015 19:10 UTC
Return-Path: <barryleiba@gmail.com>
X-Original-To: imapext@ietfa.amsl.com
Delivered-To: imapext@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 794511ACDB1; Thu, 10 Dec 2015 11:10:31 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.278
X-Spam-Level:
X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id coq-NVA0pm2c; Thu, 10 Dec 2015 11:10:29 -0800 (PST)
Received: from mail-vk0-x234.google.com (mail-vk0-x234.google.com [IPv6:2607:f8b0:400c:c05::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 172091ACDB0; Thu, 10 Dec 2015 11:10:29 -0800 (PST)
Received: by vkha189 with SMTP id a189so96984325vkh.2; Thu, 10 Dec 2015 11:10:28 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=5JHscE3XRMq4ko+kPwOTWG4ELkNRmAP+blO6EmBhk9I=; b=LK+JeN+eX7j0yx6l4Edh1IM6Tlic+EOszZnC+5DJAVLntcrYDiDp/BH64h+ckxmNjd B4aWG0CkTCT8F3j4o0Kj0Yv6P7owMrr4qo+RInsGMfdgXg7X+JNIDirMR0qgt2kXoyIh OsVrsYWXDMdiHEAts6ne19rbcjNuA/ijan1r+yMlGCgvQcAYTaY1m1HmxFJaBOgZedsT Wht6bGrxTsYch0F7cbMyC86mNA+fQdm1aXsm91d6zaw6cYx6OrqOLp8vDaVxt76IFMG5 LPu1C2x/FGCXy6AMwT2N6i7omXATIZJ5SvQ9Buwfc5/lBWcOjQmgMD3MIuNYKeIPNrGk 7ryw==
MIME-Version: 1.0
X-Received: by 10.31.2.17 with SMTP id 17mr10243745vkc.130.1449774628129; Thu, 10 Dec 2015 11:10:28 -0800 (PST)
Sender: barryleiba@gmail.com
Received: by 10.31.182.211 with HTTP; Thu, 10 Dec 2015 11:10:28 -0800 (PST)
In-Reply-To: <DEA84B8F15992B4EA87D5CF3D0EC5F98AE4FCFD8@DRTW-EXMB04.telecom.sna.samsung.com>
References: <CALaySJLE_6+vbeB-SeMk1VHDAtq2VvS9yKe9dhQ2LTzr4y=oTg@mail.gmail.com> <DEA84B8F15992B4EA87D5CF3D0EC5F98AE4FCFD8@DRTW-EXMB04.telecom.sna.samsung.com>
Date: Thu, 10 Dec 2015 14:10:28 -0500
X-Google-Sender-Auth: 4PWV26h9DSTrDs4KCKxzTHVFLuE
Message-ID: <CALaySJK=5nkmF2K0Vt7mgg2honoX9iYS4yhgu+giDjKyDoR0GQ@mail.gmail.com>
From: Barry Leiba <barryleiba@computer.org>
To: Narendra Bisht <ns.bisht@sta.samsung.com>, Adrien de Croy <adrien@qbik.com>
Content-Type: text/plain; charset="UTF-8"
Archived-At: <http://mailarchive.ietf.org/arch/msg/imapext/RSS7L0W_0NYBLNKncrwjgVeD-a0>
Cc: "draft-ietf-imapapnd-appendlimit-extension@ietf.org" <draft-ietf-imapapnd-appendlimit-extension@ietf.org>, "imapext@ietf.org" <imapext@ietf.org>
Subject: Re: [imapext] AD review of draft-ietf-imapapnd-appendlimit-extension-06
X-BeenThere: imapext@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Discussion of IMAP extensions <imapext.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/imapext>, <mailto:imapext-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/imapext/>
List-Post: <mailto:imapext@ietf.org>
List-Help: <mailto:imapext-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/imapext>, <mailto:imapext-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 10 Dec 2015 19:10:31 -0000
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 <adrien@qbik.com> 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] AD review of draft-ietf-imapapnd-append… Barry Leiba
- Re: [imapext] AD review of draft-ietf-imapapnd-ap… Barry Leiba
- [imapext] Referencing RFC 2088 (was: AD review of… S Moonesamy
- Re: [imapext] Referencing RFC 2088 Alexey Melnikov
- Re: [imapext] Referencing RFC 2088 (was: AD revie… Adrien de Croy
- Re: [imapext] AD review of draft-ietf-imapapnd-ap… Jayantheesh S B
- Re: [imapext] AD review of draft-ietf-imapapnd-ap… Narendra Bisht
- Re: [imapext] Referencing RFC 2088 S Moonesamy
- Re: [imapext] AD review of draft-ietf-imapapnd-ap… Alexey Melnikov
- Re: [imapext] Referencing RFC 2088 (was: AD revie… Naren
- Re: [imapext] AD review of draft-ietf-imapapnd-ap… S Moonesamy
- Re: [imapext] AD review of draft-ietf-imapapnd-ap… Naren
- Re: [imapext] AD review of draft-ietf-imapapnd-ap… S Moonesamy
- Re: [imapext] AD review of draft-ietf-imapapnd-ap… Naren
- Re: [imapext] AD review of draft-ietf-imapapnd-ap… Alexey Melnikov
- Re: [imapext] AD review of draft-ietf-imapapnd-ap… Alexey Melnikov
- Re: [imapext] AD review of draft-ietf-imapapnd-ap… Jayantheesh S B
- Re: [imapext] AD review of draft-ietf-imapapnd-ap… S Moonesamy
- Re: [imapext] AD review of draft-ietf-imapapnd-ap… Barry Leiba
- Re: [imapext] AD review of draft-ietf-imapapnd-ap… S Moonesamy
- Re: [imapext] AD review of draft-ietf-imapapnd-ap… Jayantheesh S B
- Re: [imapext] AD review of draft-ietf-imapapnd-ap… Jayantheesh S B
- Re: [imapext] AD review of draft-ietf-imapapnd-ap… S Moonesamy
- Re: [imapext] AD review of draft-ietf-imapapnd-ap… Stu Brandt
- Re: [imapext] AD review of draft-ietf-imapapnd-ap… Jayantheesh S B
- Re: [imapext] AD review of draft-ietf-imapapnd-ap… Adrien de Croy
- Re: [imapext] AD review of draft-ietf-imapapnd-ap… Adrien de Croy
- Re: [imapext] AD review of draft-ietf-imapapnd-ap… Stu Brandt
- Re: [imapext] AD review of draft-ietf-imapapnd-ap… Adrien de Croy
- Re: [imapext] AD review of draft-ietf-imapapnd-ap… Adrien de Croy
- Re: [imapext] AD review of draft-ietf-imapapnd-ap… Arnt Gulbrandsen
- Re: [imapext] AD review of draft-ietf-imapapnd-ap… Dave Cridland
- Re: [imapext] AD review of draft-ietf-imapapnd-ap… Dave Cridland
- Re: [imapext] AD review of draft-ietf-imapapnd-ap… Arnt Gulbrandsen
- Re: [imapext] AD review of draft-ietf-imapapnd-ap… Alexey Melnikov
- Re: [imapext] AD review of draft-ietf-imapapnd-ap… Alexey Melnikov
- Re: [imapext] AD review of draft-ietf-imapapnd-ap… Alexey Melnikov
- Re: [imapext] AD review of draft-ietf-imapapnd-ap… Alexey Melnikov
- Re: [imapext] AD review of draft-ietf-imapapnd-ap… Adrien de Croy
- Re: [imapext] AD review of draft-ietf-imapapnd-ap… Adrien de Croy
- Re: [imapext] AD review of draft-ietf-imapapnd-ap… Alexey Melnikov
- Re: [imapext] AD review of draft-ietf-imapapnd-ap… Alexey Melnikov
- Re: [imapext] AD review of draft-ietf-imapapnd-ap… Jayantheesh S B
- Re: [imapext] AD review of draft-ietf-imapapnd-ap… Jayantheesh S B
- Re: [imapext] AD review of draft-ietf-imapapnd-ap… Barry Leiba
- Re: [imapext] AD review of draft-ietf-imapapnd-ap… Bron Gondwana
- Re: [imapext] AD review of draft-ietf-imapapnd-ap… Barry Leiba
- Re: [imapext] AD review of draft-ietf-imapapnd-ap… Adrien de Croy
- Re: [imapext] AD review of draft-ietf-imapapnd-ap… Alexey Melnikov
- Re: [imapext] AD review of draft-ietf-imapapnd-ap… Narendra Bisht
- Re: [imapext] AD review draft-ietf-imapapnd-appen… Alexey Melnikov
- Re: [imapext] AD review of draft-ietf-imapapnd-ap… Barry Leiba
- Re: [imapext] AD review draft-ietf-imapapnd-appen… Stu Brandt
- Re: [imapext] AD review of draft-ietf-imapapnd-ap… Alexey Melnikov
- Re: [imapext] AD review draft-ietf-imapapnd-appen… Alexey Melnikov
- Re: [imapext] AD review of draft-ietf-imapapnd-ap… Jayantheesh S B
- Re: [imapext] AD review draft-ietf-imapapnd-appen… S Moonesamy
- Re: [imapext] AD review of draft-ietf-imapapnd-ap… Barry Leiba
- Re: [imapext] AD review of draft-ietf-imapapnd-ap… Jayantheesh S B
- Re: [imapext] AD review of draft-ietf-imapapnd-ap… Jayantheesh S B
- Re: [imapext] AD review of draft-ietf-imapapnd-ap… Adrien de Croy
- Re: [imapext] AD review of draft-ietf-imapapnd-ap… Barry Leiba
- Re: [imapext] AD review of draft-ietf-imapapnd-ap… Jayantheesh S B
- Re: [imapext] AD review draft-ietf-imapapnd-appen… Dave Cridland
- Re: [imapext] AD review of draft-ietf-imapapnd-ap… Alexey Melnikov
- Re: [imapext] AD review draft-ietf-imapapnd-appen… Alexey Melnikov
- Re: [imapext] AD review of draft-ietf-imapapnd-ap… Jayantheesh S B
- Re: [imapext] AD review of draft-ietf-imapapnd-ap… Barry Leiba