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

[Tero Kivinen <[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. 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.
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. 

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

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

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

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

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.

Host B cannot know what policy host A has, thus it cannot restrict
operations. Again this problem goes away if host B can only request
status notifications so they come to the host B envelope sender.

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

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

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

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.

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

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

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

   A delta time is used so as to prevent problems associated with
   differences in system clocks between clients and servers.  Servers in
   receipt of a valid by-parameter are expected to convert the by-time
   into a locale-specific absolute time called the deliver-by-time.

   This is done by adding the by-time upon receipt to the current
   locale-specific time and thereby arriving at a locale-specific
   absolute time which is by-time seconds in the future or past,
   depending upon the arithmetic sign of by-time.  The message is then
   to be delivered by the deliver-by-time. 

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.

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