Re: [secdir] [Last-Call] secdir review of draft-ietf-jmap-quotas
Bron Gondwana <brong@fastmailteam.com> Tue, 17 January 2023 23:22 UTC
Return-Path: <brong@fastmailteam.com>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5045AC14CE2B; Tue, 17 Jan 2023 15:22:48 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.795
X-Spam-Level:
X-Spam-Status: No, score=-2.795 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_PASS=-0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fastmailteam.com header.b="ZM5NGuj9"; dkim=pass (2048-bit key) header.d=messagingengine.com header.b="X66Wd8Rk"
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 TqzDgLemhRaN; Tue, 17 Jan 2023 15:22:44 -0800 (PST)
Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B8741C14CEE5; Tue, 17 Jan 2023 15:22:43 -0800 (PST)
Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.nyi.internal (Postfix) with ESMTP id 139075C0107; Tue, 17 Jan 2023 18:22:43 -0500 (EST)
Received: from imap43 ([10.202.2.93]) by compute3.internal (MEProxy); Tue, 17 Jan 2023 18:22:43 -0500
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= fastmailteam.com; h=cc:cc:content-type:date:date:from:from :in-reply-to:in-reply-to:message-id:mime-version:references :reply-to:sender:subject:subject:to:to; s=fm1; t=1673997763; x= 1674084163; bh=INk9geENPJxY0WJ+ZJo/uRVmpOv/s62PK9LBnl8rlLo=; b=Z M5NGuj93T8uyzmv6n/nT+KUZIr5X71gDCTQRiMgNqEDAfPV6xovh6Jfgnvatljmj MF9iYL9y5/2YMJA/wkBg4tCilEfzjSUDrC2QdEQjUHFPNDmMtNCYxZT16T9FEwgh rv13dbJE8in2Kh7f7Krr4lnm68zqsQGsEjIgmtt3QzyOBedgVqUpV4/AMiJqZwke 5d8R2TMAj5a2pCrbdBgcZkADDNAvX0Pgwgp2J3zmaDypfOaTF5zDfySMOTDtucp2 /XAYa+nVSSyf9uFIdu9SW45kjMshgQ0uKZtmsab7hfz9S3t1NdlIUdhuwy5QZRh3 587TjsIdcsmn3X7X6F0YA==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-type:date:date:feedback-id :feedback-id:from:from:in-reply-to:in-reply-to:message-id :mime-version:references:reply-to:sender:subject:subject:to:to :x-me-proxy:x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s= fm3; t=1673997763; x=1674084163; bh=INk9geENPJxY0WJ+ZJo/uRVmpOv/ s62PK9LBnl8rlLo=; b=X66Wd8Rk/Ikuj3puYM6hAYFZtdLQT1Q8lR94ZcXuk/xE dtmuBZlwdzvZokWDWVVCRcN8/EQwHv7hMHhQK52SYZ4tpjVEkUgygqfWcNiYtref PhAJ5GmB2na2OQb0IMAQXBeutyA6jYpiBj/d6/cl8qwycFVMOAIrAVigBhFoOwqB x83vgPzKHGlNXEDxHmmriGwiT4R9+u+3j2lXsupzLYVya8zMipYGiTQvNUMh8OcA yljRo9uYZyPzi392Y0jDiETnjoHFfmGWKCTwGujJYu5zRBTrl8DfPjMqSW4gkdfB TK5auHAHRcfmTPyb3LCG/GRiv8wDilLB0n4TXh44Zw==
X-ME-Sender: <xms:wi3HY19lqylnpHsr2xUCzmYSR3CuFHcsVImqZNKhCeR2cL8PsymKdA> <xme:wi3HY5ufl9gFlCO-17iJmzFnVB8r0PgibdUWLqm6Zt27e4hQumVxL106zdCc69YcZ 8GPVijsjGs>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvhedruddtjedguddtucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepofgfggfkjghffffhvfevufgtsegrtderreerredtnecuhfhrohhmpedfuehr ohhnucfiohhnugifrghnrgdfuceosghrohhnghesfhgrshhtmhgrihhlthgvrghmrdgtoh hmqeenucggtffrrghtthgvrhhnpeegueehfeegueefveeiudelueelvdegtdehffeltdel ffeuiefgueekkeektedtvdenucffohhmrghinhepihgvthhfrdhorhhgnecuvehluhhsth gvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomhepsghrohhnghesfhgrshht mhgrihhlthgvrghmrdgtohhm
X-ME-Proxy: <xmx:wi3HYzCPOPazGLIq0BdzOlOtgbtW6jb0eUrif4KSjTuGfwV3-Biy9g> <xmx:wi3HY5eD3Yv8k93kKLX69Z32UFWbGDyI4fOARYESteIQ2l7NdMwoFQ> <xmx:wi3HY6N1Ag8VGquZDXjsj8_0fpdFy9rWrjEWh1jdDGIuJzvuMXwIjA> <xmx:wy3HY3oIAG8ZVnoS1vuqaFWUtSj2pmJ7aTybauIr1CET9XsdWd1OwQ>
Feedback-ID: i2d7042ce:Fastmail
Received: by mailuser.nyi.internal (Postfix, from userid 501) id A048A2D40447; Tue, 17 Jan 2023 18:22:42 -0500 (EST)
X-Mailer: MessagingEngine.com Webmail Interface
User-Agent: Cyrus-JMAP/3.9.0-alpha0-85-gd6d859e0cf-fm-20230116.001-gd6d859e0
Mime-Version: 1.0
Message-Id: <bebadcbf-5b0c-4ba7-8c4c-804c26dcbe61@betaapp.fastmail.com>
In-Reply-To: <ybl1qo0hgkp.fsf@wd.hardakers.net>
References: <ybl1qo0hgkp.fsf@wd.hardakers.net>
Date: Wed, 18 Jan 2023 10:22:22 +1100
From: Bron Gondwana <brong@fastmailteam.com>
To: René CORDIER <rcordier@linagora.com>
Cc: Wes Hardaker <wjhns1@hardakers.net>, draft-ietf-jmap-quotas.all@ietf.org, jmap@ietf.org, last-call@ietf.org, secdir@ietf.org
Content-Type: multipart/alternative; boundary="1cab297b3e3b4124af5c4216f0d0d074"
Archived-At: <https://mailarchive.ietf.org/arch/msg/secdir/84Rv05CTXhIyxIsTYnurs9jOvKw>
Subject: Re: [secdir] [Last-Call] secdir review of draft-ietf-jmap-quotas
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/secdir/>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 17 Jan 2023 23:22:48 -0000
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