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

From: Ben Campbell <[email-masked]>
Date: Wed, 09 Jan 2019 13:51:29 -0800

Ben Campbell has entered the following ballot position for
draft-ietf-extra-sieve-fcc-08: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-extra-sieve-fcc/

----------------------------------------------------------------------
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. This seems analogous to the "fileinto"
action. I looked for security considerations for that in RFC 5228. All I found
was a statement that "fileinfo" can be dangerous, but no elaboration on the
nature of the danger or how it might be mitigated. So while I agree that fcc
would have similar considerations as "fileinfo", I'm not sure those
considerations have been adequately documented.  (I expect people will point me
to something I missed, or where some other analogous feature is documented, in
which case I will clear.)

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

§1, last paragraph (nit): Should "each action" be "each new action"?

§3.2, construction for FCC-OPTS: There is no extension point among the options,
which would seem to require any new options update this RFC. Would it be
reasonable to add one?

---

From: Alexey Melnikov <[email-masked]>
Date: Thu, 10 Jan 2019 08:42:56 +0000

Hi Ben,

> On 9 Jan 2019, at 21:51, Ben Campbell <[email-masked]> wrote:
> 
> 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?

In particular, what are the possible privacy implications?

Thank you,
Alexey
> This seems analogous to the "fileinto"

---

From: Ben Campbell <[email-masked]>
Date: Thu, 10 Jan 2019 08:56:16 -0600

> On Jan 10, 2019, at 2:42 AM, Alexey Melnikov <[email-masked]> wrote:
> 
> Hi Ben,
> 

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?

> In particular, what are the possible privacy implications?

Could there be issues with, say, shared mailboxes? Or storing cleartext for mail that would be sent encrypted?

I suspect the answers may be more IMAP related than sieve related, but even that might suggest citing something IMAP related.

Ben.

---

From: Alexey Melnikov <[email-masked]>
Date: Thu, 10 Jan 2019 15:14:59 +0000

Hi Ben,

On Thu, Jan 10, 2019, at 2:56 PM, Ben Campbell wrote:
> 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.

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

> I suspect the answers may be more IMAP related than sieve related, but 
> even that might suggest citing something IMAP related.

Best Regards,
Alexey

---

From: Ben Campbell <[email-masked]>
Date: Thu, 10 Jan 2019 09:29:03 -0600

> On Jan 10, 2019, at 9:14 AM, Alexey Melnikov <[email-masked]> wrote:
> 
> Hi Ben,
> 

Doesn’t that make the safety of storing the message dependent on having reasonable protections for the owner’s mailboxes?

---

From: Alexey Melnikov <[email-masked]>
Date: Thu, 10 Jan 2019 16:23:13 +0000

On Thu, Jan 10, 2019, at 3:29 PM, Ben Campbell wrote:
>> On Jan 10, 2019, at 9:14 AM, Alexey Melnikov
>> <[email-masked]> wrote:>> 
>> Hi Ben,
>> 
>>>> On Jan 10, 2019, at 2:42 AM, Alexey Melnikov
>>>> <[email-masked]> wrote:>>>> 
>>>> Hi Ben,
>>>> 
>>>>> ------------------------------------------------------------------
>>>>> ---->>>>> 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 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.
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
>

---

From: Ben Campbell <[email-masked]>
Date: Thu, 10 Jan 2019 10:27:29 -0600

> On Jan 10, 2019, at 10:23 AM, Alexey Melnikov <[email-masked]> wrote:
> 
>>> On Jan 10, 2019, at 9:14 AM, Alexey Melnikov <[email-masked] <mailto:[email-masked]>> wrote:
>>> 
>>> Hi Ben,
>>> 
>>>>> On Jan 10, 2019, at 2:42 AM, Alexey Melnikov <[email-masked] <mailto:[email-masked]>> wrote:
>>>>> 
>>>>> Hi Ben,
>>>>> 
>>>>>> On 9 Jan 2019, at 21:51, Ben Campbell <[email-masked] <mailto:[email-masked]>> wrote:
>>>>>> 
> 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.

---

From: Alexey Melnikov <[email-masked]>
Date: Thu, 10 Jan 2019 16:36:06 +0000

Hi Ben,

On Thu, Jan 10, 2019, at 4:27 PM, Ben Campbell wrote:
>> On Jan 10, 2019, at 10:23 AM, Alexey Melnikov
>>>>>> <[email-masked]> wrote:>>>>>> 
>>>>>> Hi Ben,
>>>>>> 
>>>>>>> ----------------------------------------------------------------
>>>>>>> ------>>>>>>> DISCUSS:
>>>>>>> ----------------------------------------------------------------
>>>>>>> ------>>>>>>> 
>>>>>>> Thanks for the work on this. I plan to ballot "yes", but have
>>>>>>> one item I think>>>>>>> needs to be discussed first:
>>>>>>> 
>>>>>>> considerations>>>>>>> not already present in [RFC5228], [RFC5230], [RFC5435], and
>>>>>>> [RFC6131]. I'm not>>>>>>> sure that that is true.
>>>>>>> 
>>>>>>> mailbox might have>>>>>>> security and/or privacy considerations.
>>>>>> 
>>>>>> putting the user (Sieve script owner) over quota?>>>>> 
>>>>> 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?>>>>> 
>>>>> Or storing cleartext for mail that would be sent encrypted?>>>> 
>>>> 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 .>>> 
>>> having reasonable protections for the owner’s mailboxes?>> IMAP access already requires TLS, so all message retrieval is already
>> over encrypted channel.> 
Sieve can talk directly to the mailstore over local API, IPC, some
proprietary protocol, etc. This is not in scope for this document.
> 
> 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.
>  vs data-in-motion question.
> 
>> 
>>>>> related, but>>>>> even that might suggest citing something IMAP related.
>>>> 
>>>> Best Regards,
>>>> Alexey
Best Regards,
Alexey

---

From: Ben Campbell <[email-masked]>
Date: Thu, 10 Jan 2019 10:42:40 -0600

> On Jan 10, 2019, at 10:36 AM, Alexey Melnikov <[email-masked]> wrote:
> 
> Hi Ben,
> 
>>> On Jan 10, 2019, at 10:23 AM, Alexey Melnikov <[email-masked] <mailto:[email-masked]>> wrote:
>>> 
> 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.

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

---

From: Ned Freed <[email-masked]>
Date: Thu, 10 Jan 2019 09:53:12 -0800 (PST)

> just skeptical that the answer is “no new considerations." 

I think this is demonstrably true.

I'll first note that in terms of the sorts of messages it is capable of
generating, the enotify extension with mailto: is effectively a superset of
vacation. (Vacation is much more convenient to use and includes some additional
builtin checks, but these aren't relevant here.)

So it suffices to consider the notify :fcc case.

Now compare the following sieves, each belonging to [email-masked]:

[1]

require ["enotify", "fcc"];
notify :fcc "INBOX.Sent" :message "Bob got mail!" "mailto:[email-masked]";

[2]

require ["enotify", "fileinto"];
if header :is "subject" "Bob got mail!" {
  fileinto "INBOX.Sent";
}
else {
  notify :message "Bob got mail!" "mailto:[email-masked]?to=[email-masked]";
}

In case this isn't clear, the first script uses :fcc to make a copy of the
notification and file it while the second uses a second notification recipient,
test, and a fileinto to make the copy and file it. The results will likely
differ in minor ways, e.g., Received: fields will probably be different, but
since :fcc is constrained to have essentially the same semantics as fileinto,
the security considerations aren't going to differ much if at all.

The use of :fcc with actions defined in the future may result in additional
security considerations, but we won't know what those are until it happens.

Of course this also sidesteps the issue of whether or not the security
considerations for fileinto are properly documented. 

> The authors of
> 5228 thought “fileinto” could be dangerous. Do we know why?

Yes, but I doubt you'll care for the answer much. (I certainly don't.) First,
it's pretty obvious that there are risks with using fileinto. Off the top of my
head:

(1) Lost messages. An incorrectly set up fileinto, or a correct one that's
    set up and then forgotten can result in important messages being put in a
    place where nobody bothers to look.

(2) Excessive disk usage. Lots of sites have automatic rules for cleaning out
    unread messages from commonly used mailboxes like INBOX or Junk. However,
    the assumption tends to be that since other folders have to be set up
    manually that they should have longer expiration times or not be subject
    to expiration policies at all.

(3) Breaking non-idempotent workflows. Fileinto can be used to create
    additional copies of messages, and this can have bad effects on
    processors (including people) that fail to check for duplicates.

(4) Creating large numbers of mailboxes. Combine fileinto and Sieve
    variables with a bit of carelessness, and you can achieve some
    spectacular results. Example:

    require ["fileinto", "variables"];
    # File tagged list mail in an appropriate folder.
    if header :matches "subject" "*[*]*" { fileinto "List-${2}"; }

    (I note that this issue is described in more general terms in RFC 5229.)

And so on. Similar lists can also be constructed for discard, redirect,
ereject, etc.

But here's the thing: Are these really the sorts of things that need to be
listed in a security considerations section? Sure, they all have potential
security ramifications, but the common factor in all of these is that somebody
did something dumb. And the list of dumb things is effectively endless. Do we
need to caution against having

    discard;

or

    require "fileinto"; fileinto "Junk";

as your entire Sieve script? And if not, where do we draw the line?

And perhaps more to the point, there's little if anything a Sieve implementer
can do to prevent people from doing dumb things. In every case I've listed
above - including the last two examples - there's a legitimate use-case  that
isn't dumb.

Note: Speaking as someone who supports a Sieve implementation, users definitely
do dumb things with sieves on a regular basis. In fact if I could add one
recommendation to the base document, it would be that Sieve implementations
running at or just before final delivery SHOULD log all actions the user' Sieve
takes. Including explicit keep. Logging makes it possible to tell users what
happened, and in most cases why. Of course the log then has privacy issues ...

Even worse, we've now opened the door to a bunch of meta-issues that are well
known to be ratholes: Exactly who is the target audience for security
considerations? Where do we draw the line between "Obvious problem but
sufficiently dangerous to be worth belaboring" and "Duh!!!"? Etc.

And this brings us back to what's in RFC 5228. What's in there and what's not
is a result of the fact that the process that produced that text in both RFC
3228 and 5228 was - and I'm being generous here - distinctly suboptimal.

I don't think it's productive to get into the specifics of what went wrong, so 
let me just say that ratholes were involved, and by the time we extricated
ourselves from those there was neither sufficient energy nor sufficient
patience to try and flesh out what dangerous aspects of various actions needed
to be discussed and which ones didn't. So we stuck in a dangerous bend sign and
left it at that.

In any case, while I acknowledge that the security considerations in RFC 5228
could and should be improved, I think doing so in a document that provides -
let's face it - a power user feature and which is therefopre unlikely to be
consulted by base specification implementors doesn't meet a cost-benefit
analysis. I therefore support the text Alexey has suggested which I think goes
just far enough.

				Ned

---

From: Ben Campbell <[email-masked]>
Date: Thu, 10 Jan 2019 16:16:32 -0600

> On Jan 10, 2019, at 11:53 AM, Ned Freed <[email-masked]> wrote:
> 
> 
> 

I absolutely agree the security considerations for fcc are similar, perhaps identical, to those for fileinto.

> considerations for fileinto are properly documented.

That is my concern.

> listed in a security considerations section?

I don’t think they all are. I’m primarily concerned about things that could unintentionally expose information to third parties. I guess data loss could be a secondary concern, but I’m not as concerned about that.

In email discussion so far, the only things that have come up that seem to fit that is filing into a shared mailbox, or into a mailbox that is otherwise not well protected.

> Sure, they all have potential

My point was not to do a post-mortum on 5228, or to try to fix it. I’m only concerned about any issue there to the extent that _this_ draft relies on it.

> analysis. I therefore support the text Alexey has suggested which I think goes

I think it’s likely that I agree; which text that Alexey suggested do you refer to? If it’s down to mentioning shared mailboxes and moving on, I’m fine with it at this point.

Thanks!

Ben.

---

From: Ned Freed <[email-masked]>
Date: Fri, 11 Jan 2019 07:30:56 -0800 (PST)

> I’m primarily concerned about things that could unintentionally expose
> information to third parties. I guess data loss could be a secondary concern,
> but I’m not as concerned about that.

Since :fcc is handled locally the risk devolves down to whether or not the
wrong someone can access the message after delivery.

> In email discussion so far, the only things that have come up that seem to
> fit that is filing into a shared mailbox, or into a mailbox that is otherwise
> not well protected.

Exactly. But this does gets back to what extent we want to warn people about
doing dumb stuff.

> ...

> My point was not to do a post-mortum on 5228, or to try to fix it. I’m only
> concerned about any issue there to the extent that _this_ draft relies on it.

> I think it’s likely that I agree; which text that Alexey suggested do you
> refer to? If it’s down to mentioning shared mailboxes and moving on, I’m
> fine with it at this point.

See:

  https://mailarchive.ietf.org/arch/msg/extra/QcBHaAziCwHJJ4gvbO2XXB8IPB8

The proposal is to cover the shared folder issue as it relates to these sorts
of messages as well as the possibility of quota issues.

				Ned

---

From: Ben Campbell <[email-masked]>
Date: Fri, 11 Jan 2019 12:07:55 -0600

> On Jan 11, 2019, at 9:30 AM, Ned Freed <[email-masked]> wrote:
> 
>  https://mailarchive.ietf.org/arch/msg/extra/QcBHaAziCwHJJ4gvbO2XXB8IPB8 <https://mailarchive.ietf.org/arch/msg/extra/QcBHaAziCwHJJ4gvbO2XXB8IPB8>
> 

I am fine with that proposal. I will clear my DISCUSS.

Ben.

---

From: Ken Murchison <[email-masked]>
Date: Sat, 12 Jan 2019 10:16:55 -0500

Hi Ben,

Thanks for the review.

> COMMENT:

The intention is that a new option could be added as such:

FCC-OPTS /= ":foo"

or

FCC-OPTS /= BAR

BAR = ":bar" string

Is this insufficient or simply not clear from the text?

-- 

Ken Murchison
Cyrus Development Team
FastMail US LLC