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

Michael Slusarz <> Wed, 03 April 2019 23:02 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 8EE671202C9; Wed, 3 Apr 2019 16:02:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.3
X-Spam-Status: No, score=-4.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id j0A_3lbhmSJX; Wed, 3 Apr 2019 16:02:15 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 363CA1202C3; Wed, 3 Apr 2019 16:02:11 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 5A4CE6A23E; Thu, 4 Apr 2019 01:02:09 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;; s=201705; t=1554332529; bh=g6+yXZ7MDPLLd5tx4QFAlN/fO641wK1AKjG2k78K3M4=; h=Date:From:To:Cc:In-Reply-To:References:Subject:From; b=7JBBhIcBddzRbIEOHVZYV684VJ4hGUuloY8X6Q4j8x6c3lMRBMJEun9932bngHhEV bjGXMbbUwqNim7mUxvB+Lm/Lfj1hx6+B2vFohHEG/cAuCcIinz7xeU36+tmaHB83jI xv9N2SIXVGk+2YtyS+M4ixZOaVpe9SjvXS/2NrOiC2EAQ2PCtMOpmMB56dDkymVvfY DyrdfnbQnsq4ZcHwNLmENHYmxqKTsE6VepeL/r4VTBrtCpVJyHsbQ97LICE1ql80ch tgGZqiaHXwKQ7lhjyYcOxLa6Tw1LTZcoLRi9lCN5zS6RtdbyaIx9VkPEYey2uhsNwb NuXtzDMdRmXcg==
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPSA id 4CF3C3C0399; Thu, 4 Apr 2019 01:02:09 +0200 (CEST)
Date: Wed, 03 Apr 2019 17:02:09 -0600
From: Michael Slusarz <>
To: Stefan Santesson <>, Stefan Santesson via Datatracker <>,
Message-ID: <>
In-Reply-To: <>
References: <>
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
X-Priority: 3
Importance: Medium
X-Mailer: Open-Xchange Mailer v7.10.1-Rev10
X-Originating-Client: open-xchange-appsuite
Archived-At: <>
Subject: Re: [secdir] Secdir last call review of draft-ietf-extra-imap-fetch-preview-03
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Security Area Directorate <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 03 Apr 2019 23:02:18 -0000

Hello Stefan,

Thanks for your review.  Comments below.

> On March 22, 2019 at 4:44 AM Stefan Santesson via Datatracker <> 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.