Re: [Extra] Ben Campbell's Discuss on draft-ietf-extra-sieve-fcc-08: (with DISCUSS and COMMENT)

Ben Campbell <ben@nostrum.com> Thu, 10 January 2019 16:27 UTC

Return-Path: <ben@nostrum.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 29356130E71; Thu, 10 Jan 2019 08:27:47 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.678
X-Spam-Level:
X-Spam-Status: No, score=-1.678 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, HTML_MESSAGE=0.001, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=nostrum.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 xnAPzCT6kIsm; Thu, 10 Jan 2019 08:27:45 -0800 (PST)
Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 78751127133; Thu, 10 Jan 2019 08:27:45 -0800 (PST)
Received: from [10.0.1.45] (cpe-70-122-203-106.tx.res.rr.com [70.122.203.106]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id x0AGRUkA058633 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Thu, 10 Jan 2019 10:27:32 -0600 (CST) (envelope-from ben@nostrum.com)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nostrum.com; s=default; t=1547137653; bh=uxnPX6iFDcBaKp4hne/kpxuCz1wAgZ8qWbnAJKzipF8=; h=From:Subject:Date:In-Reply-To:Cc:To:References; b=BilJjv7VIzw2RAIejbmaZSUaGrzDyrzn7H0FfvxzzVXWz4dXGUDZa8xuL8zaA9yr/ xw+cVfNzffwQuTMuLA9YH0asQpGPb/QAwLeMMcvJdGwR0W6W/BgPW+1JBc3r14trw/ c9oyNEQ5m/CjBtCAjMKd8MV3exHya3pNmZhnoKG4=
X-Authentication-Warning: raven.nostrum.com: Host cpe-70-122-203-106.tx.res.rr.com [70.122.203.106] claimed to be [10.0.1.45]
From: Ben Campbell <ben@nostrum.com>
Message-Id: <3CCF615E-6ABF-4681-BF75-A205B7B1B10E@nostrum.com>
Content-Type: multipart/signed; boundary="Apple-Mail=_4F5586F1-0F4D-4809-88F3-177BEAD6C956"; protocol="application/pgp-signature"; micalg=pgp-sha512
Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\))
Date: Thu, 10 Jan 2019 10:27:29 -0600
In-Reply-To: <1547137393.3825651.1631025328.2D213854@webmail.messagingengine.com>
Cc: extra@ietf.org, yaojk@cnnic.cn, draft-ietf-extra-sieve-fcc@ietf.org, The IESG <iesg@ietf.org>, extra-chairs@ietf.org
To: Alexey Melnikov <aamelnikov@fastmail.fm>
References: <154707068927.5028.9965727374137648132.idtracker@ietfa.amsl.com> <553C69A0-9D9F-45F7-9586-B0BD71DF2661@fastmail.fm> <9DF727DF-068E-437D-B8E1-D3A71A087DE3@nostrum.com> <1547133299.3806739.1630945640.44BE5606@webmail.messagingengine.com> <1C3A8600-2EF7-4339-BD05-5C642476C0D7@nostrum.com> <1547137393.3825651.1631025328.2D213854@webmail.messagingengine.com>
X-Mailer: Apple Mail (2.3445.102.3)
Archived-At: <https://mailarchive.ietf.org/arch/msg/extra/rW5hZSPK87s7Gwo1rJYoNHrjUyc>
Subject: Re: [Extra] Ben Campbell's Discuss on draft-ietf-extra-sieve-fcc-08: (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, 10 Jan 2019 16:27:47 -0000


> On Jan 10, 2019, at 10:23 AM, Alexey Melnikov <aamelnikov@fastmail.fm>; wrote:
> 
> On Thu, Jan 10, 2019, at 3:29 PM, Ben Campbell wrote:
>>> On Jan 10, 2019, at 9:14 AM, Alexey Melnikov <aamelnikov@fastmail.fm <mailto:aamelnikov@fastmail.fm>> wrote:
>>> 
>>> Hi Ben,
>>> 
>>> On Thu, Jan 10, 2019, at 2:56 PM, Ben Campbell wrote:
>>>> 
>>>> 
>>>>> On Jan 10, 2019, at 2:42 AM, Alexey Melnikov <aamelnikov@fastmail.fm <mailto:aamelnikov@fastmail.fm>> wrote:
>>>>> 
>>>>> Hi Ben,
>>>>> 
>>>>>> On 9 Jan 2019, at 21:51, Ben Campbell <ben@nostrum.com <mailto:ben@nostrum.com>> wrote:
>>>>>> 
>>>>>> ----------------------------------------------------------------------
>>>>>> DISCUSS:
>>>>>> ----------------------------------------------------------------------
>>>>>> 
>>>>>> Thanks for the work on this. I plan to ballot "yes", but have one item I think
>>>>>> needs to be discussed first:
>>>>>> 
>>>>>> The security considerations say that this extension adds no new considerations
>>>>>> not already present in [RFC5228], [RFC5230], [RFC5435], and [RFC6131]. I'm not
>>>>>> sure that that is true.
>>>>>> 
>>>>>> It seems like the ability to insert a copy of message into a mailbox might have
>>>>>> security and/or privacy considerations.
>>>>> 
>>>>> Can you give me an idea of what you have in mind here, other than putting the user (Sieve script owner) over quota?
>>>> 
>>>> I can’t say that I know what the security considerations might be; I’m
>>>> just skeptical that the answer is “no new considerations." The authors
>>>> of 5228 thought “fileinto” could be dangerous. Do we know why?
>>> 
>>> I don't remember now, even though I participated in the discussion.
>>> 
>>>>> In particular, what are the possible privacy implications?
>>>> 
>>>> Could there be issues with, say, shared mailboxes?
>>> 
>>> Possibly. I can write something about this.
>>> 
>>>> Or storing cleartext for mail that would be sent encrypted?
>>> 
>>> I can't think of how this is going to be possible. Sieve notifications/vacation replies can disclose private information from Sieve script owner, but storing such messages doesn't leak any more information (ignore shared folders, I agree this might be an issue), because such messages will be stored in one of owner's mailboxes .
>> 
>> Doesn’t that make the safety of storing the message dependent on having reasonable protections for the owner’s mailboxes?
> IMAP access already requires TLS, so all message retrieval is already over encrypted channel.

Is sieve limited to working only over IMAP?

Even if “yes”, that's a data-at-rest vs data-in-motion question.

> 
> If you meant something else, can you please elaborate?
>>> 
>>>> I suspect the answers may be more IMAP related than sieve related, but
>>>> even that might suggest citing something IMAP related.
>>> 
>>> Best Regards,
>>> Alexey