[secdir] secdir review of draft-ietf-jmap-quotas

[Wes Hardaker <[e-mail]>]

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/