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

[Ben Campbell <[e-mail]>]

> On Jan 10, 2019, at 10:36 AM, Alexey Melnikov <[e-mail]> 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 <[e-mail] <mailto:[e-mail]>> wrote:
>>> 
>>> On Thu, Jan 10, 2019, at 3:29 PM, Ben Campbell wrote:
>>>>> On Jan 10, 2019, at 9:14 AM, Alexey Melnikov <[e-mail] <mailto:[e-mail]>> 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 <[e-mail] <mailto:[e-mail]>> wrote:
>>>>>>> 
>>>>>>> Hi Ben,
>>>>>>> 
>>>>>>>> On 9 Jan 2019, at 21:51, Ben Campbell <[e-mail] <mailto:[e-mail]>> 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