Re: [Extra] Roman Danyliw's Discuss on draft-ietf-extra-imap-fetch-preview-03: (with DISCUSS and COMMENT)

Michael Slusarz <michael.slusarz@open-xchange.com> Thu, 11 April 2019 01:58 UTC

Return-Path: <michael.slusarz@open-xchange.com>
X-Original-To: extra@ietfa.amsl.com
Delivered-To: extra@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A28D4120151; Wed, 10 Apr 2019 18:58:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.3
X-Spam-Level:
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: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=open-xchange.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ENTwLd8WQ9-o; Wed, 10 Apr 2019 18:58:31 -0700 (PDT)
Received: from mx4.open-xchange.com (alcatraz.open-xchange.com [87.191.39.187]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 56926120163; Wed, 10 Apr 2019 18:58:31 -0700 (PDT)
Received: from open-xchange.com (imap.open-xchange.com [10.20.30.10]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx4.open-xchange.com (Postfix) with ESMTPS id 8BD826A25F; Thu, 11 Apr 2019 03:58:29 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=open-xchange.com; s=201705; t=1554947909; bh=dtsf+U9SJtjLf6DHA5dAbdvpfWQXX0+xAoeCQZs3qZ0=; h=Date:From:To:Cc:In-Reply-To:References:Subject:From; b=7iRhkA9RqJ0hBDtLR9OdRfSXyuDpeM7/JJYeTy7ekpZQ/Ng4kyZ3HqPrv6sln8EC1 udSMDI7rXLuoUNMTjaICa+pqW1tf2P3KdIGS5Cx1oxALE68Btm+kl7t4LAi/X5kkrb ROuqW6JuO3qa3Aj0swUHI1EUfDffGT37UqcIPHVhmdeiOFArDn84RslvMWkPy+bxkW T4JzgsF7KNi9nAFbvr1SfBKjDTbPB4KTj8nZXtFVE6ht9pvgiVmjSKqi/MVyLL4GXn 59U9scwwBOXK2Tg1RaaOACyuxdMcp71Bdhv/1PSlDyZCFnee5FI2fBft9mwt1TdR9S wdEcwv8SH05ZA==
Received: from appsuite-gw2.open-xchange.com (appsuite-gw2.open-xchange.com [10.20.28.82]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by open-xchange.com (Postfix) with ESMTPSA id 7238E3C00AB; Thu, 11 Apr 2019 03:58:29 +0200 (CEST)
Date: Wed, 10 Apr 2019 19:58:29 -0600 (MDT)
From: Michael Slusarz <michael.slusarz@open-xchange.com>
To: Roman Danyliw <rdd@cert.org>, Roman Danyliw via Datatracker <noreply@ietf.org>, The IESG <iesg@ietf.org>
Cc: extra@ietf.org, brong@fastmailteam.com, extra-chairs@ietf.org, draft-ietf-extra-imap-fetch-preview@ietf.org
Message-ID: <270245125.18005.1554947909394@appsuite.open-xchange.com>
In-Reply-To: <155432299793.22684.17651098563381437965.idtracker@ietfa.amsl.com>
References: <155432299793.22684.17651098563381437965.idtracker@ietfa.amsl.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
X-Priority: 3
Importance: Medium
X-Mailer: Open-Xchange Mailer v7.10.1-Rev10
X-Originating-Client: open-xchange-appsuite
Archived-At: <https://mailarchive.ietf.org/arch/msg/extra/SCKo9QIJuwPbXQxVBZl-yH_Wl5g>
Subject: Re: [Extra] Roman Danyliw's Discuss on draft-ietf-extra-imap-fetch-preview-03: (with DISCUSS and COMMENT)
X-BeenThere: extra@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Email mailstore and eXtensions To Revise or Amend <extra.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/extra>, <mailto:extra-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/extra/>
List-Post: <mailto:extra@ietf.org>
List-Help: <mailto:extra-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/extra>, <mailto:extra-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 11 Apr 2019 01:58:34 -0000

Roman,

Thanks for your comments.  See below:

> On April 3, 2019 at 2:23 PM Roman Danyliw via Datatracker <noreply@ietf.org> wrote:
> 
> ----------------------------------------------------------------------
> DISCUSS:
> ----------------------------------------------------------------------
> 
> (1) Retention practices of cached previews
> Section 1 says “Using server generated previews allows global generation once
> per message, and then cached indefinitely”.  Why cache indefinitely, especially
> if the source messages has been expunged?  For privacy reasons, couldn’t this
> caching be consistent with the retention of the email.
> 
> In Section 9, Security Considerations, there needs to be discussion of this
> retention too.  Perhaps text like: “Implementations that pre-generate and store
> previews MUST ensure that the stored preview is also deleted when the
> corresponding mail message is expunged.”

Agree with your comments (and Barry and Alexey) that this language can be improved.  I implemented better language last week in the draft ... but unfortunately I can't access those changes at the moment as our RCS system is involved in a public cloud outage.  Once back online, I'll share the revised text.

> (2) Protection of previews at rest
> In Section 9, Security Considerations, there needs to be discussion about the
> potential sensitivity of these previews and the need to protect them.  Perhaps
> text like: “Just as the messages they summarize, previews may contain sensitive
> information.  When stored, these previews MUST be protected with equivalent
> authorization and confidentiality controls as the source message.”

My recollection is that I added this text, or a slight derivation of it, to the Security section.

> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
>
> (2) Section 3.1, the paragraph “If no algorithm identifier is provided, the
> server decides …” discusses algorithm identifiers but their use hasn’t been
> introduced yet.  I recommend swapping the order of this paragraph with the
> current third paragraph (“Alternative …”) as this is where algorithms are
> introduced.
> 
> (3) Section 4.1.  Duplicate word. s/to the the language/to the language/
> 
> (4) Section 4.1.  Nit on word order. s/no human-readable text to generate
> preview information from/no human-readable text from which to generate preview
> information/
> 
> (5) Section 7.  In the ABNF comments, consider using “[RFC6648]” instead of
> “RFC 6648”.

Fixes to these various nits were added to the draft.  Per Barry's reply, I did not implement the proposed RFC 8174 changes.

michael