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

[Ned Freed <[e-mail]>]

> I have reviewed this document as part of the security directorate's
> ongoing effort to review all IETF documents being processed by the
> IESG.  These comments were written primarily for the benefit of the
> security area directors.  Document editors and WG chairs should treat
> these comments just like any other last call comments.

> This draft provides two things. Firstly it will provide ability for
> sieve email filtering program to see the delivery status notification
> and deliver by information from the envelope. Secondly it allows
> setting those same parameters when using sieve redirect action.

> The first part does not have security issues, but the second might
> have, as it causes delivery notify emails to be sent which were not
> originally requested by the original author.

THis really isn't the issue, or more precisely, if this is an issue warranting
such great concern this isn't the place to address it.

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 can cause problems for the original sender, as he is now getting
> the deliver status notifications which he has not requested. The draft
> does not explictly specify, but I do assume that the sieve redirect
> keeps the original sender intact,

Sieve redirect is defined in RFC 5228 and it doesn't specify whether the
original address is used or the address of the Sieve owner. (What it does say
is that if the original message had an empty envelope from, any redirected
message must also have an empty envelope from. This prevents certain especially
pernicious loops from forming, but I don't see it as relevant to this
discussion.)

Considering redirect behavior further, it does raise an issue that needs to be
addressed in this document, but it's a usability issue, not a security issue.
Specifically, what does it mean to add a DSN request or activate deliverby
when you don't know where these notifications are going to go? This ruins
the usability of both redirect-dsn and redirect-deliverby. I therefore
propose adding the following text to redirect-dsn and similar text to
redirect-deliverby:

  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. 

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

> The number of delivery status notifications can be quite large,
> especially if the ":bytrace" option of the redirect is used, as then
> every single future step for email processing, will send "relayed"
> status notification, and if there is for example mail loop or similar,
> this can be several dozen of status notifications.

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?

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

But if there is no such restriction, then it simply doesn't matter what
we do in Sieve, because nobody is going to bother using Sieve when direct
usage is simpler, easier and less likely to be detected.

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

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.
I do not feel strongly about this, however, so if others feel this should be
allowed I'll be happy to change it. (The other argument, and in my view more
reasonable, argument in favor of the change is that this would mean the
parameter would have to be a string rather than an counting number, and that
would allow variables to be used.)

> Section 5 also says that the "bytime" is "the initial integer part of
> the delive-by extension", but then comments that deliver-by by-time is
> decremented as message passes through the transport infrastructure.
> This does not make it clear whether the sieve filtering system should
> also decrement the number while message is waiting to be processed.
> I.e. if message was received earlier, but it took some time before the
> sieve email filter could be run on the message, should the "bytime" be
> the original time from the smtp MAIL FROM BY= part, or whether it is
> decremented.

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

And again, if this really bothers you, this draft is not the place to address
the issue.

Be that as it may, I actualy the the draft is pretty clear on this point. It
says:

  When these arguments are specified, they are used to construct the
  corresponding BY ESMTP MAIL FROM parameter. The :bytime value becomes
  the by-time, the :bymode becomes the by-mode value, and :bytrace
  sets the by-trace modifier.

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.

> Also the example in 5.1 is wrong, as it is only true if the sieve
> filter is run exactly when the deliver-by expired. It should compare
> whether the "bytime" is <= 0, not whether it is equal to 0 (note, that
> if tye bymode is "return" then the "bytime" never should reach 0, as
> at that point mail is returned to the sender.

Yep, this is broken, and moreover the fix isn't that simple because
the i;ascii-numeric comparator only handles unsigned values.  I've updated the
text to address this issue.
 
> In section 7 it should be made clear that ":bytime" parameter "<limit:
> number>" can be negative too, but it seems that RFC 5228 specifies
> that numbers can only be non-negative so I am not sure whether the
> usage is correct or not.

That's only true if we decide to allow specification of negative values.
However, I did add a note saying that negative values cannot be specified.

Thanks for the comments - very useful. I'll post a revision once there's
agreement on the envelope sender text and whether or not to change :bytime.

				Ned