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

Roman Danyliw <rdd@cert.org> Thu, 25 April 2019 18:44 UTC

Return-Path: <rdd@cert.org>
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 3F9E912023F; Thu, 25 Apr 2019 11:44:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.001
X-Spam-Level:
X-Spam-Status: No, score=-2.001 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_NONE=-0.0001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cert.org
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 7aM_HLTSnV7G; Thu, 25 Apr 2019 11:44:40 -0700 (PDT)
Received: from veto.sei.cmu.edu (veto.sei.cmu.edu [147.72.252.17]) (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 3145B120227; Thu, 25 Apr 2019 11:44:40 -0700 (PDT)
Received: from delp.sei.cmu.edu (delp.sei.cmu.edu [10.64.21.31]) by veto.sei.cmu.edu (8.14.7/8.14.7) with ESMTP id x3PIiY2L040086; Thu, 25 Apr 2019 14:44:34 -0400
DKIM-Filter: OpenDKIM Filter v2.11.0 veto.sei.cmu.edu x3PIiY2L040086
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cert.org; s=yc2bmwvrj62m; t=1556217874; bh=8kojQT7WZJ7c3aclBM5fzC01oyApy/f5OoLWmORzyMo=; h=From:To:CC:Subject:Date:References:In-Reply-To:From; b=nf5eRkwUst+t/qX779mmQKal6JcqQ73XuxsfddsqXaROrpMJN4yqzzdZ5IK5Zbs2G EjqBdMlPcwtptIXGCQ0iWpoVMdtKNvswBRqHxeZFI24fk4P9r1WC8z9c1seqSwEfuz 6JAGSMe9e1/7Y2if3Ko4I/dOVKwh5lQhrntvzJXQ=
Received: from CASSINA.ad.sei.cmu.edu (cassina.ad.sei.cmu.edu [10.64.28.249]) by delp.sei.cmu.edu (8.14.7/8.14.7) with ESMTP id x3PIiXNC026921; Thu, 25 Apr 2019 14:44:33 -0400
Received: from MARATHON.ad.sei.cmu.edu ([10.64.28.250]) by CASSINA.ad.sei.cmu.edu ([10.64.28.249]) with mapi id 14.03.0439.000; Thu, 25 Apr 2019 14:44:32 -0400
From: Roman Danyliw <rdd@cert.org>
To: Michael Slusarz <michael.slusarz=40open-xchange.com@dmarc.ietf.org>, "The IESG" <iesg@ietf.org>
CC: "extra@ietf.org" <extra@ietf.org>, "brong@fastmailteam.com" <brong@fastmailteam.com>, "extra-chairs@ietf.org" <extra-chairs@ietf.org>, "draft-ietf-extra-imap-fetch-preview@ietf.org" <draft-ietf-extra-imap-fetch-preview@ietf.org>
Thread-Topic: [Extra] Roman Danyliw's Discuss on draft-ietf-extra-imap-fetch-preview-03: (with DISCUSS and COMMENT)
Thread-Index: AQHU6lsdU9pkh6o9mkWEzi03EGhTD6Y2gnWAgBbS0cA=
Date: Thu, 25 Apr 2019 18:44:29 +0000
Message-ID: <359EC4B99E040048A7131E0F4E113AFC01B334911F@marathon>
References: <155432299793.22684.17651098563381437965.idtracker@ietfa.amsl.com> <270245125.18005.1554947909394@appsuite.open-xchange.com>
In-Reply-To: <270245125.18005.1554947909394@appsuite.open-xchange.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.64.22.6]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/extra/fFj7x1CNhWQqRITgh8kThi63QDY>
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, 25 Apr 2019 18:44:42 -0000

Hi Michael!

Thanks for the -04 update.  Comments below ...

> -----Original Message-----
> From: iesg [mailto:iesg-bounces@ietf.org] On Behalf Of Michael Slusarz
> Sent: Wednesday, April 10, 2019 9:58 PM
> To: Roman Danyliw <rdd@cert.org>rg>; Roman Danyliw via Datatracker
> <noreply@ietf.org>rg>; The IESG <iesg@ietf.org>
> Cc: extra@ietf.org; brong@fastmailteam.com; extra-chairs@ietf.org; draft-
> ietf-extra-imap-fetch-preview@ietf.org
> Subject: Re: [Extra] Roman Danyliw's Discuss on draft-ietf-extra-imap-fetch-
> preview-03: (with DISCUSS and COMMENT)
> 
> 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.

It doesn't look like the revised text to address the retention issue made it into -04.  Furthermore, the new language in Section 9, "If stored permanently, ..." reiterates my concern. 

> > (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.

The new text addresses my concern.  Thanks.

> > ----------------------------------------------------------------------
> > 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.

Looks good.  Thank you.

Roman