Re: [Last-Call] secdir review of draft-ietf-jmap-quotas
rcordier@linagora.com Thu, 19 January 2023 03:35 UTC
Return-Path: <rcordier@linagora.com>
X-Original-To: last-call@ietfa.amsl.com
Delivered-To: last-call@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 66201C1522D5; Wed, 18 Jan 2023 19:35:58 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.692
X-Spam-Level:
X-Spam-Status: No, score=-1.692 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=neutral reason="invalid (public key: not available)" header.d=linagora.com
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XWUsBWy09oCL; Wed, 18 Jan 2023 19:35:54 -0800 (PST)
Received: from smtp.linagora.com (smtp.linagora.com [54.36.8.78]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0011EC1524A3; Wed, 18 Jan 2023 19:35:51 -0800 (PST)
Received: from ?Open?PaaS?SMTP?server?for?Linagora? (unknown [51.83.109.124]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.linagora.com (Postfix) with ESMTPSA id B484C3EE1D; Thu, 19 Jan 2023 04:35:47 +0100 (CET)
DKIM-Signature: a=rsa-sha256; b=tmj9lcARAeomz/rqP5IokjOPpDHneDvtC3Ruu4SYlTOTOyO47zaEUtjrXMmwTRpjFdnXvWVbIsdshrCXB9NF+FT5s6iR7xU/2jEmdPbAdgr+vjzp28EbOIEV//XRBLteqboO8kdl17sbmpJwfliHGhOl6+V74xxDxRUzWI1mkjI1FEky601kaf/1x8U8jBZgdZ2YDTMnAKmNuYZA14f2omelAx2SDDlo72i3dAD22BTSAIIF+Q1AKNxntwZ4VqADsUK7yQWxFa3ZDYvMfeM67/USWINdO0gV9ugpF/jF39Y6Y/QSfICP4/trZU8XwApGmlnHnrB9MYD1Gldb7kevLQ==; s=smtpoutjames; d=linagora.com; v=1; bh=Rob76XRmRZalApnnldOCVugVVT01QYoMcjLbEBw+KTo=; h=from : reply-to : subject : date : to : cc : resent-date : resent-from : resent-sender : resent-to : resent-cc : in-reply-to : references : list-id : list-help : list-unsubscribe : list-subscribe : list-post : list-owner : list-archive;
Date: Thu, 19 Jan 2023 03:35:48 +0000
Message-ID: <757653176.44.1674099348721@212e230e4d2f>
MIME-Version: 1.0
X-LINAGORA-Copy-Delivery-Done: 1
From: rcordier@linagora.com
To: Bron Gondwana <brong@fastmailteam.com>
Cc: Wes Hardaker <wjhns1@hardakers.net>, draft-ietf-jmap-quotas.all@ietf.org, jmap@ietf.org, last-call@ietf.org, secdir@ietf.org
Reply-To: rcordier@linagora.com
User-Agent: Team-Mail/0.5.2 Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/109.0.0.0 Safari/537.36
Content-Type: multipart/alternative; boundary="-=Part.73.fca46b217af9c260.185c818d27d.cd9f9a482072a3b4=-"
Archived-At: <https://mailarchive.ietf.org/arch/msg/last-call/FTqdaFAtm22sgcEwhXsfwdMphFc>
Subject: Re: [Last-Call] secdir review of draft-ietf-jmap-quotas
X-BeenThere: last-call@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: IETF Last Calls <last-call.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/last-call>, <mailto:last-call-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/last-call/>
List-Post: <mailto:last-call@ietf.org>
List-Help: <mailto:last-call-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/last-call>, <mailto:last-call-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 19 Jan 2023 03:35:58 -0000
Hello all, Apologies I've been quite off for the last month or so as well. Like Wes, well numerous life events in my case too. But I should now have time again to address soon enough the concerns I got. I will answer Wes concerns but also everybody else that took the time this last month to review and comment on the jmap quota draft. Just bear with me a bit longer and we should be fine I believe :) Best regards, Rene. On Jan 18, 2023 6:22 AM, from Bron Gondwana Rene, can you please address this review. Hopefully we're close to ready now! Thanks, Bron. On Thu, Jan 12, 2023, at 09:06, Wes Hardaker wrote: I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. Review summary: almost ready with issues Apologies for my delay in getting to the new version of this document (between vacation and a bad cold, I got behind in tasks). Thank you for the work you put into the new version; I find it much better than the old and can see you took many suggestions (mine and others) into account. A few (mostly minor) thoughts on the new version: - If it were me, I'd break the quota attributes section into it's own (becoming a new 4.1) starting with "The quota object MUST...". - 4.1: document at section 5.1 -> document in section 5.1 - 4.3: any of which may be omitted -> any of which may be included or omitted - 4.3: seems odd that the name attribute is the only one that isn't a list. - 4.3: Larger issue wrt interoperability: My last note leads to the next: in the summary paragraph you state "A Quota object matches the FilterCondition if and only if all the given conditions match, including multiple array elements existing within a condition.", which I don't know how to interpret properly. You say that all conditions match (which I'm sure means if both a scope and a resourceType are specified they both MUST match). But the second part of the sentence leaves me confused about multiple array elements. This would leave me to think that if you specified multiple resourceTypes in a list, then every type must match which should never be true so I doubt this is what you mean. Maybe this is a good rewrite: A Quota object matches the FilterCondition if and only if all the given properties match (i.e. a logical and of all properties). For filter properties that are a list, at least one of the list elements must match for that property to be considered a match (i.e. a logical or of all the property's list element). But... I am trying to figure out what you mean, and my interpretation may be wrong! - For the example in section 5.2, I'd suggest actually using data that followed the previous example in a time-sequence. Thus, if you changed the "sinceState" to "78540" to match the last value from the previous example, it would better show an example of commands over time. (IMHO) - The security section is improved (thank you), but there are some wording issues within it that need work: - "so he shouldn't know" -- I think you mean other users here shouldn't know. So I'd change this to "so other users shouldn't know" or "no users should know". - The last sentence is hard to read as is. I'd suggest the following replacement: In order to limit those attacks, quotas with "domain" or "global" scope SHOULD only be visible to server administrators and not to general users. - I'm surprised you don't have an acknowledgment section, which customary to list all the people that help you put this specification together. It's common but not required of course. -- Wes Hardaker USC/ISI -- last-call mailing list last-call@ietf.org https://www.ietf.org/mailman/listinfo/last-call -- Bron Gondwana, CEO, Fastmail Pty Ltd brong@fastmailteam.com