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:43 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 1A58F130E86; Thu, 10 Jan 2019 08:43:07 -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 FOZvWHdR4VbF; Thu, 10 Jan 2019 08:43:05 -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 2B5BC130E90; Thu, 10 Jan 2019 08:43:05 -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 x0AGgfRS061068 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Thu, 10 Jan 2019 10:42:42 -0600 (CST) (envelope-from ben@nostrum.com)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nostrum.com; s=default; t=1547138563; bh=mTO6bXVmr9yOdru7pQp0+f5Ehz1aYN2KRYNWCOi7boI=; h=From:Subject:Date:In-Reply-To:Cc:To:References; b=Xv1fixD0bDR9PCpY8uiWtrjKFCK45+v9BRIT6vDhqVYs9SA9b+1hY7Gi72gaejR8S 1y4FuQ268+n607AlhyMA/PTSxi2jEIn9c4FckW8LGAmEQgGcQZvFeng2xMBUABkjRv 2Q/E6WBp/GqkAMBP0iQfD1kRcyartup0TV7Z7cZo=
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: <931CF4CC-EE58-4B32-A877-0D58005FF29F@nostrum.com>
Content-Type: multipart/signed; boundary="Apple-Mail=_0C4B27DA-0353-4BAA-A9B1-FBC717AA27D4"; 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:42:40 -0600
In-Reply-To: <1547138166.3829145.1631037600.2E0CCD71@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> <3CCF615E-6ABF-4681-BF75-A205B7B1B10E@nostrum.com> <1547138166.3829145.1631037600.2E0CCD71@webmail.messagingengine.com>
X-Mailer: Apple Mail (2.3445.102.3)
Archived-At: <https://mailarchive.ietf.org/arch/msg/extra/elkn6jYUUjGQiPKwGdcilcpiDog>
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:43:07 -0000


> On Jan 10, 2019, at 10:36 AM, Alexey Melnikov <aamelnikov@fastmail.fm>; wrote:
> 
> Hi Ben,
> 
> On Thu, Jan 10, 2019, at 4:27 PM, Ben Campbell wrote:
>>> On Jan 10, 2019, at 10:23 AM, Alexey Melnikov <aamelnikov@fastmail.fm <mailto: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?
> Sieve can talk directly to the mailstore over local API, IPC, some proprietary protocol, etc. This is not in scope for this document.

I’m not saying it should be in scope, but if the security properties depend on a particular protocol being used it’s worth mentioning that.

> 
>> 
>> Even if “yes”, that's a data-at-rest
> How messages are stored in any particular mailstore is outside the scope of both Sieve or IMAP. This was never specified in any RFC and this is not something unique to FCC anyway. But if you can suggest some specific text to add, the WG can discuss it.

I was thinking something as simple as “The privacy properties for data stored in any given mailbox depends on the access protocol used and the underlying protections for the mailbox itself”. That may seem obvious, but sometimes we need to state the obvious.

> 
>> 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
> Best Regards,
> Alexey