Telechat Review of draft-ietf-mailmaint-imap-uidbatches-20
review-ietf-mailmaint-imap-uidbatches-20-secdir-telechat-geater-2026-02-08-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.

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