Last Call Review of draft-ietf-jmap-quotas-07
review-ietf-jmap-quotas-07-secdir-lc-hardaker-2022-11-17-00
Request | Review of | draft-ietf-jmap-quotas |
---|---|---|
Requested revision | No specific revision (document currently at 12) | |
Type | Last Call Review | |
Team | Security Area Directorate (secdir) | |
Deadline | 2022-11-19 | |
Requested | 2022-11-05 | |
Authors | René Cordier | |
I-D last updated | 2022-11-17 | |
Completed reviews |
Secdir Last Call review of -07
by Wes Hardaker
(diff)
Artart Last Call review of -07 by Marco Tiloca (diff) Genart Last Call review of -10 by Thomas Fossati (diff) Secdir Telechat review of -10 by Wes Hardaker (diff) |
|
Assignment | Reviewer | Wes Hardaker |
State | Completed | |
Request | Last Call review on draft-ietf-jmap-quotas by Security Area Directorate Assigned | |
Posted at | https://mailarchive.ietf.org/arch/msg/secdir/z098hZ9VcO1z16oa14gbuBkhTsU | |
Reviewed revision | 07 (document currently at 12) | |
Result | Has issues | |
Completed | 2022-11-16 |
review-ietf-jmap-quotas-07-secdir-lc-hardaker-2022-11-17-00
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 Document wide comments: the document reads fairly well, but some of the sections are rather short and terse making them hard to understand. Note that I don't have extensive JMAP background, but have reviewed at least parts of the JMAP spec in order to understand this document better. Security specific comments: 1. Though the document says that all of the security requirements from RFC8620, it might be helpful to list which of each of the sections within 8620 apply specifically to this document. EG, transport and authentication are likely JMAP-wide and handled above this specification, but JSON parsing certainly applies directly to this extension. 2. The "security and privacy considerations" bullet in the IANA section references section 4, but: A. the security considerations is section 3 and B. there is no privacy considerations in either this document or in RFC8620. Which brings me to: 3. One problem with domain/global quota access is that querying for it and the changes can be used to reveal information about other accounts. EG, say user1 and user2 are both on some mail alias, but its subscription list is considered private so neither knows the other is there. By comparing the quota count before and after user1 sends a message to the list will reveal the number of people on the list, as the domain or global count will go up by the number of people subscribed. These attacks are harder to pull off, but with careful thought you can come up with all sort of privacy leaking attacks. So I suggest at least mentioning that revealing domain and global counts to all users may cause privacy leakage of other sensitive data, or at least the existence of other sensitive data. 4. related and not entirely a security specific comment, except that it may be resource consuming to support it: For section 2.4: do you think implementations will really support Quota/queryChanges? That would amount to the server remembering and listing every change in quota value over time? Which would functionally amount to every time a count or storage size changes it would need to remember that point in time. I [IMHO] would be tempted to say that Quota/queryChanges is not supported unless there is a real use case for it. Other comments/suggestions: 1.2: "with that specific capitalization" is an odd phrase. How about "when capitalized" instead? 1.4.1: "applies for this account" -> "applies to just the client's account" 2. the first sentence is very hard to parse. I suggest rewriting it, maybe into two parts to increase clarity. 2. limit: "if we reach" -> "if the client reaches" (we doesn't make sense here) 3. datatypes: "of all the data types values that are applying to this quota" -> "of the data types that apply to this quota". [in general, this entire item could use some word-smithing] 4. general: should the warnLimit and softLimit should's be SHOULDs? 2.2: with respect to back-references: it could be useful to see an example of this in the examples section. 2.3: "if all the given conditions match" -> "if all the given conditions match, including multiple array elements existing within a condition" 2.3: note that sorting isn't really described here. Is every type of field sortable? I recognize it's discussed more fully in RFC8620, so maybe referencing the right section in that would be helpful to the reader. -- Wes Hardaker My Pictures: http://photos.capturedonearth.com/