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. The summary of the review is READY WITH NITS. Summary ======= This is a good draft with a clearly defined scope and strong supporting information. Being a well contained extension to a very well understood and widely implemented spec it rightly mostly relies on historic work for Security Concerns. However, while it already acknowledges its greatest security issue and offers mitigations, it is the opinion of this reviewer that think there are nits in how well it explains and enforces those mitigations. Most of these observations are actually not strictly security related, but since implementation complexity and diversity can increase attack surface I consider them worth nothing. Hopefully they are helpful. Security Nits ============= Denial of service opportunities ------------------------------- The document already notes that the batch creation operation may be resource intensive and points at DOS possibilities, but in this reviewer's opinion does not go far enough in defining server-side mitigations, spending instead more time on defining when a client may make new requests. In situations like this it is generally bad practice to rely on a well-behaved client and consideration should be given to upgrading some MAYs to MUSTs and adding a line to the Security Considerations that server implementations are at the very least strongly advised to implement default-deny on subsequent calls unless one of the conditions in 3.1.1 is met. Greater violation of sequence number discovery than expected? ------------------------------------------------------------- The document is at pains to point out that it weakens the prohibition of use of sequence numbers in UIDONLY mode, and has some mitigations in terms of size and rate limits, since very small batch sizes would open the door here. However, is it possible to perform sequence number attacks *after* the first 500? Eg by asking for 500, then 501, 502, …? Again if the solution to this is the prohibition on clients making multiple calls, perhaps the normative guidance to servers should be stronger. Multiple clients? ----------------- Given the heavy reliance in this document on limiting client calls and re-computation of batches, what is the impact of having multiple clients open on the same mailbox? Why wouldn't they trip over each other's calls? Is this all dependent on the server caching results and recomputing after a condition of 3.1.1 is met, regardless of which client issues the call? If so, again more normative guidance to servers might result in a more robust population of implementations. Other Nits ========== Usage and usefulness of OPTIONAL batch_range -------------------------------------------- The specific behaviour of `batch_range` seems slightly ambiguous and potentially unusable. Given that the server can: * return batches of a smaller size than that requested, and ... * ... not necessarily even the same size for each batch * include UIDs that don't exist * change batch boundaries on subsequent calls how on Earth can the client know for sure which start and end range to pick? Seems like significant opportunity for clipping issues or invalid local state assumptions. And complexity in handling such things in a client that has to interface with a multitude of server implementations could lead to cascade faults. Potentially confusing error return ---------------------------------- Given the description of the 'NO' response in 3.1, shouldn't the examples in 3.1.5 and 3.1.6 be 'NO', not 'OK Complete'? Given commentary elsewhere in the document isn’t requesting batches beyond the mailbox size “exceeding limits” and therefore warranting of a NO response? 'Completed' ----------- The empty return returns 'OK Completed' rather than 'OK [number]'. Shouldn't 'Completed' therefore be part of the formal syntax in 4? Or is it considered inherited from earlier specs? In good faith, Jon Geater