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

[Ned Freed <[e-mail]>]

> > On Jan 10, 2019, at 2:42 AM, Alexey Melnikov <[e-mail]> wrote:
> >
> > Hi Ben,
> >
> >> On 9 Jan 2019, at 21:51, Ben Campbell <[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." 

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 [e-mail]:

[1]

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

[2]

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

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