Re: [secdir] Review of draft-freed-sieve-notary-07

[Ned Freed <[e-mail]>]

> Ned Freed writes:
> > All this extension does is give a user access to existing site capabilities
> > through Sieve. If those capabilities are available, a user can use or abuse
> > them directly far more easily than they can through Sieve.
> >
> > The only scenario where this presents an added exposure is one where
> > these capabilities can be accessed through Sieve but not through
> > regular submission or SMTP. If such a setup were created, it would
> > be a fairly wierd thing - so wierd I really cannot see much point in
> > worrying about it. But even so, this particular case is specifically
> > dealt with by the current security considerations.

> This all depends what envelope sender is used for redirects.

Not really. Again, since regular submit/SMTP allows specification of *any*
envelope sender, and Sieve piggybacks off that capability, the only added
exposure this extension provides is if the restrictions on redirect are for
some reason less than what's on submit/SMTP itself. And that case is already
explicitly covered in the security considersions section.

> If
> original author envelope sender is used, then normally there is no way
> to enable sending deliver status notifications to the original sender
> for email in transit, usually the original sender must request it.

Sure there is. All I have to do is resubmit the message, specifying the
original sender but adding whatever NOTIFY options I choose. At most Sieve
offers a different way to get at this functionality; it doesn't offer the
functionality itelf.

> This feature adds option to someone else to request them (but see the
> text later about this).

> >   RFC 5228 does not require any particular envelope sender address
> >   be associated with redirected messages. However, the redirect-dsn
> >   extension isn't terribly useful if the place where the delivery
> >   status notifications are sent isn't known. Accordingly, when
> >   either :notify or :ret is specified and the envelope sender
> >   address isn't empty, implementations MUST set the envelope sender
> >   address to the address of the sieve owner.

> This text will address the problem as after this it is not possible
> for someone else to request status notification for original author,
> i.e with this text added the problem mentioned earlier disappears.

It prevents it from being done using Sieve, yes, but that's not the reason for
making the change and doesn't change the fact that the security issue you've
described does not exist in any meaningful sense.

> > > so the deliver status notification
> > > messages are sent to the original author, not to the user doing the
> > > redirect.
> >
> > That's one possible behavior, but if someone wants to create intentional
> > backscatter, it is far simpler to just connect to the submit port and say:
> >
> >     MAIL FROM:<target>
> >     RCPT TO:<whoever> NOTIFY=SUCCESS,FAILURES
> >     DATA
> >     blah blah
> >     .

> With trace option you get amplification factor, i.e. you only need
> send one message and that can generate multiple messages back.

And the trace option is also available via submit/SMTP, so this is a
distinction without a difference.

> > The same arguments hold for DELIVERBY. If the extension is available, why
> > not just (ab)use it directly? Why bother with a convoluted path through
> > Sieve that will almost certainly leave a much bigger trail?

> If the relayed status notifications go to the original author instead
> of the sieve filter owner, then the attacker does not need to send
> any emails, the victim attacks himself by sending email to attackers
> address which will then add trace option to the email on the fly.

Now please explain the significant advantage this provides to an attacker. It's
not like sending emails is hard.

> This attack goes away if status notifications always go to the sieve
> owner.

Yes, but you have failed to make the case that this "attack" is worth worrying
about.

> > > This should most likely be mentioned in the security considerations
> > > section more clearly. The security considerations section do warn
> > > about generating status notification, and says that
> >
> > >   "Sites which limit the ability to request success notifications will
> > >    also need to restrict the ability to request them using the
> > >    redirect-dsn extension."
> >
> > > but that does not help at all, as if the original senders site limits
> > > the ability to request notifications, the host running sieve email
> > > filter of the receiver might not have such restrictions, thus receiver
> > > can enable them even when they were forbidden from the sender.

> > You're missing the point. If the site restricts notification requests in some
> > way, e.g, you can only request a success notification if the envelope from is
> > local, then that restriction also needs to apply to redirect-dsn and
> > redirect-deliveryby, because if it doesn't you've left a hole someone could
> > exploit.

> Yes, I understood that, but depending what envelope sender is used for
> those status notification there is ANOTHER problem.

A problem which the security considerations already address.

> Say host A limits DSN notification complately, i.e does not allow them
> at all. Now host A user A sends email to user B on host B whose sieve
> filter adds status notifications (as they are not restricted on host
> B, only on host A) and the status notifications go to original author
> A. Now host A user A will get status notifications even when the host
> A policy forbid requesting them.

In other words, this is a case where the Sieve policy for requesting DSNs is
more lenient that for submit/SMTP. I agree this is a security concern, which is
why the security considerations section of the document addresses it. It says:

  Sites which limit the ability
  to request success notifications will also need to restrict the ability
  to request them using the redirect-dsn extension.

> Host B cannot know what policy host A has, thus it cannot restrict
> operations.

Not only can it know, it has to. This is what administrators are for - to
implement consistent policies across hosts.

And if you don't have consistent administrative policies for email handling the
set of issues we're discussing here are going to be the absolute least of your
problems.

> Again this problem goes away if host B can only request
> status notifications so they come to the host B envelope sender.

Actually, no, it doesn't. It may prevent the mechanism from being used to
create backscatter, but inconsistent administrative policies open the door to
all sorts of other bad behavior.

> > > Also in section 5, it should be made clear that the "bytime" can also
> > > be negative, if the bymode is "notify" and the message is already
> > > pasts is notification time.
> >
> > Unfortunately, RFC 2852 predates the current thinking in email that
> > there's significant semantic difference between submission and
> > relay. My understanding of the purpose of negative by-times is that
> > they are arrived at when a message exceeds the time limit but still
> > needs to be delivered. If there's a justification for having a
> > negative by-time on initial submission I haven't heard it. In fact
> > had RFC 2852 distinguished between submit and relay I suspect it
> > would have disallowed negative by-times in the submit case.

> I do not thing this is relevant here.

On the contrary, it's entirely relevant because what we have done by requiring
the resetting of the envelope sender is to effectively require that these
extended redirect be considered as a new submission, not a relay operation.

> > And since the use of this extension effectively means the message is
> > being resubmitted, I don't see any reason to allow negative by-times
> > to be specified.

> It might be needed if the sieve filter wants to preserve by-time
> values given to it in the beginning. I do not know enough of Sieve to
> know if it is possible, but one use could be using sieve to for
> example limit the by-time to something, i.e. wants to make sure that
> when email is redirected to cellular phone it is delivered before
> certain time (for example before 22:00, because user does not want to
> wake up when cellular phone beeps in the middle of night), unless the
> email already had shorted by-time, in which case it wants to preserve > it.

The short answer is ths use-case you describe here really isn't feasible
in Sieve, for a bunch of different reasons.

THe longer answer is that this ends up being infeasible because:

(1) Sieve doesn't have enough numeric and time computation facilities to
    perform the sort of limit operation you describe.

(2) Even if you could do the calculation, or if, say, there was a related
    use-case where limiting the relative value made sense (I confess I cannot
    come up with one where it does), most Sieve implementations operate
    after final delivery, so copying deliver-by information doesn't really
    make sense.

(3) A script that does something like this really needs to know what
    sort of Sieve implementation it is dealing with before doing it. In
    particular, it needs to know if the Sieve is operating before or
    after final delivery. It turns out this can be determined, but it
    requires an additional extension - the environment extenion and the
    "phase" item, e.g.,

    "phase"   => The point relative to final delivery where the
                 Sieve script is being evaluated.  Possible values are
                 "pre", "during", and "post", referring respectively to
                 processing before, during, and after final delivery
                 has taken place.

(4) A script that tries to do this and doesn't check the phase could
    result in bad behavior.

I think all of this conspires to make this particular use-case one not worth
worrying about. But again, this isn't something I feel strongly about, so if
the consensus is to change it I will do so.

> In that case the by-time could be already negative when user redirects
> the email.

Actually, no. In the use-case you describe, the goal is to prevent the phone
from ringing after a certain point. That implies that a by-mode of "R" has to
be used, which means no negative by-times are allowed.

Moreover, if the original mode was "R", you can copy over a shorter by-time.
But what happens if the mode is "N"? I think in that case you'd want to
ignore the original by-time in order to get sensible behavior.

All that said, this use-case makes me wonder if the real error here is that we
aren't providing a way to look at and set by-times as absolute, rather than
relative, time values.

> Also I think the Sieve should be able to preserve by-time and envelope
> sender when it redirects email, if it does not ADD new notifications.

> I.e if someone sends email having by-time saying it needs to be
> delivered during next hour, and the Sieve forwards it to the cellular,
> it would be useful to keep that same time limit there, and it would
> also be nice if the original author still gets the status
> notifications he asked for.

That's totally outside the purview of this extension, which does not and cannot
deal with the unextended redirect case. Moreover, the lack of specificity about
when Sieve operates - which is both intentional and essential -  makes this a
very difficult question to address in ANY context. Just as one example, you
most certainly do NOT want to try and preserve these things if Sieve is
operating in a user agent weeks after final delivery - which is a perfectly
legitimate and  even common situation.

If this really concerns you, the place to address it is in the Sieve base
specification. Feel free to propose changes there if/when that specification is
revised.

> If the sieve owner asks for additional notifications they should come
> to sieve owner, not to the original author.

Agreed and already addressed.

> > I first have to say that if the timing is so critical that this sort
> > of thing really matters, you're pretty much sunk before you start.
> > For better or worse the DELIVERBY extension only applies while mail
> > is in transit, and there's an increasing amount of stuff that
> > happens outside of this context (e.g., downloads from a POP3/IMAP4
> > server) that cannot be traced or "timed out").

> If the email is not yet delivered to the local mail box, but is
> redirected to somewhere else by the Sieve then I do consider the email
> to still be in transit, and the time used to run the Sieve should be
> taken in to account. In most cases it does not really matter as
> running it is very fast, but I think it still needs to be counted for.

Sieve implementations that operate at this point are in fact the exception,
not the rule.

> > I think this makes it clear the values are simply passed unchanged
> > to the SMTP/submit server. But if you want to suggest a specific
> > change, that's fine.

> I think RFC 2852 is very clear that you are supposed to convert that
> DELTA time to absolute time upon receipt of email, and then convert it
> back to delta time when you send email forward:

Yes, I'm well aware of what it says, and why. I carpool to work every day with
the guy who wrote it. The reason for this text is so that implementations won't
carelessly lose track of some amount of elapsed time. But again, this only
works while messages are in transit. I'm not convinced there's an issue worth
addressing in the Sieve case.

> Hmm.. actually it would be more accordingly to the RFC2852 to not give
> out the delta time to Sieve, but instead the deliver-by-time (which is
> locale-specific absolute time instead), and leave the processing of
> negative and positive delta times for the email service instead of
> Sieve filter.

Given how Sieve is situated in regards to final delivery, I once again disagree
that RFC 2852 provides justification for such a change. THat said, I think the
change is worth considering for other reaons, first that Sieve is equipped to
deal with with absolute time values better than it is with relative ones, and
second, that there are quite a few reaonsable use-cases for setting an absolute
:by-time.

But this is a somwwhat complex topic, and this message is already very long, so
I'm going to defer discussing this to a separate message.

> This of course depends whether Sieve has time and date data format,
> i.e. if those can be expressed in Sieve in a way where they can
> processed. This would allow it easier to for example to set
> delivery-by-time so that no email is delivered to your cellular phone
> after certain time (i.e. it is bounced back if it is tried to deliver
> after that).

That's not going to be an easy effect to get, but more on that later.

				Ned