Re: [secdir] Secdir last call review of draft-ietf-extra-imap-fetch-preview-03

[Michael Slusarz <[e-mail]>]

Hello Stefan,

Thanks for your review.  Comments below.

> On March 22, 2019 at 4:44 AM Stefan Santesson via Datatracker <[e-mail]> wrote:
> 
> However the security consideration section seems to lack relevant information.
> The current security considerations section raise the threat of DOS attacks.
> It is, however, not clear to me how the risk of DOS is affected or mitigated by
> the fact that request for preview data is restricted to authenticated clients.
> A discussion of this seems at least to be relevant for the context.

Background: the security consideration section is adapted from similar text in the CONVERT (RFC 5259) security considerations section.

Denial of server attacks here are exclusively due to authenticated users issuing PREVIEW generation commands.  DOS would occur by exhausting local server resources.  This kind of DOS attack is similar to DOS attacks that can be done with core IMAP commands available for authenticated users (e.g. excessive FETCHs, APPEND floods).  To that extent, we could add additional language from 5259 to this document along the lines of:

"In order to mitigate such attacks, servers SHOULD log the client authentication identity on
FETCH operations in order to facilitate tracking of abusive clients."

...although, this is not exclusive to PREVIEW extension so maybe this is something that can/should be added more generally to imap4rev2 (in draft) Security Considerations.

The only algorithm defined in this document is a text-parsing algorithm, so theoretically there are security considerations involved in this text parsing.  However, IMAP servers are required to do all sorts of text parsing in order to return FETCH data so this extension is not adding a different security risk that already doesn't exist with base RFC 3501 functionality.  I would be fine with adding a line stating that all security risks associated with base IMAP spec are applicable to this document also.

michael