inline ...
On Aug 25, 2007, at 9:37 AM, Alexey Melnikov wrote:
> Cullen Jennings wrote:
>
> > I don't think that is really implementable advice - it basically
> > wishes the problem away.
What advice are you talking about here? I see nothing in the revised text that
would argue for the sort of analysis of sieve scripts you're (quite correctly)
saying is impossible.
> It is implementable, it applies to UIs and admin tools and many
> implementations already follow it.
So the topic I was questioning the implementability of is a program
that can look a series of sieve scripts across one or more email
servers and decide if the sieve scripts are capable of creating large
scale message amplification attacks.
Sounds to me like you and Alexey are talking at cross purposes here, but in
regards to the question of whether what you're talking about is implementable:
It isn't, although not for the reasons you give.
The main reason it is unimplementable is very simple: Email is an Internet-wide
service and no program can possibly have the administative access to the entire
Internet it would need to perform such a check. As a specific example, I have
email accounts at Sun, on my home systems, Gmail, and a bunch of other places.
All, I repeat _all_, of these services allow me to easily configure
autoforwarding to multiple destinations. I will also point out that while
several of these systems provide Sieve support, none of them require the use of
sieve for me to set up this sort of autoforwarding. (OK, to be fair I have no
idea what's underneath the hood at Gmail, but if the other aspects of their
filtering interface are any indication it is not Sieve-based.)
To put this more concisely: It is clearly impossible to devine the intent of an
autoforwarder that is operating as part of a much larger web of autoforwarders
just by looking at it in isolation, and it is equally impossible to assess the
properties of other autoforwarders located in other administrative domains. It
follows that analyzing autoforwarders to prevent construction of mail bombs is
inherently unimplementable. (Believe it or not, some faciities in X.400
actually depended on this being possible. You can probably guess how well that
worked out...)
The draft clearly does not
contain enough information to tell someone how to implement this and
personally I seriously doubt that it is possible due to the halting
problem.
I believe my preceeding argument demonstrates that the question of Sieve's
Turing completeness is completely irrelevant to the matter at hand.
Nevertheless, since several people apparently continue to think this is an
important point I will elaborate on it a little further.
A Sieve in isolation is pretty clearly not Turing complete - no real loops - so
the at that level at least the halting problem doesn't enter into it.
Now, Eric Rescorla once argued that Sieve should be considered Turing complete
because you could bounce a message back and forth between multiple systems,
using the message content to store the position on the tape.
Even if you ignore the critical point that Sieve not being Turing complete was
always about whether or not a sieve script in isolation could cause a infinite
loop and wedge up your server and never about whether or not Sieve could
function as a component in a larger, Turing complete system, the problem with
this argument is that Recieved: field counting nails you pretty quickly for
regular messages, and once again you're left without the loop construct you
need to make it "work".
This then leaves you with no alternative but to try and use other, wierder
sorts of loops. The obvious one to try, and the one Eric proposed, is what I
call a "bounce loop": Redirect to a known-invalid address, get the bounce back,
redirect again, bounce again, etc. But bounce loops are only possible if some
agent in the path is willing to change the empty envelope from that is required
in the bounce message to refer to some other address in the forwarding path.
Without that happening a bounce cannot itself generate a bounce, so the loop
stops after at most two iterations.
This last point actually raises a general issue for autoforwarders - they MUST
NOT override an empty envelope from because if they do they can create bounce
loops. (I note in passing that in practice this is almost always happens
accidentally, not intentionally. Nevertheless, it is a very real problem that
email systems have to deal with.) RFC 2821 should have made this a requirement
but didn't. I plan to raise this issue in the context of 2821bis but I would
not object to changing the closing text in section 4.2 of the Sieve base
specification to say:
The envelope sender address on the outgoing message is chosen by the
sieve implementation. It MAY be copied from the message being
processed. However, if the message being processed has an empty
envelope sender address the outgoing message MUST also have an
empty envelope sender address.
More generally, one of the primary goals of the design of the email
infrastructure is that _all_ autoforwarding loops, once underway, can be
detected and stopped. It is _not_ a design goal to prevent such loops from
being set up - any system that tried to enforce that would be much too
restrictive.
If follows that the ability to construct an undetectable loop means there's a
serius design or the implementation flaw that needs to be corrected. But the
fact that such flaws might enable Sieve to be Turing complete is entirely
trivial compared to the other serious issues undetectable loops raise.
Getting back to the script complexity issue, since Sieve allows arbitrary
boolean expressions script analysis is pretty clearly equivalent to the
satisfiability problem, i.e. it's NP-complete, and that puts full analysis of
arbitrary sieves out of reach of anything short of a quantum computer, which
AFAIK means it effectively cannot be done. So that's another reason why you're
correct in saying this kind of analysis is impossible to perform on Sieve
scripts. But since AFAICT nobody is proposing performing such an analysis,
this doesn't change anything.
Of course I suspect it is not possible because I am also
very incredulous of the WG's claim that sieve coupled with common
email systems is not turing complete.
To be blunt, your incredulity fails to impress, let alone persuade. If you
believe such a thing is possible then prove it by giving the details of how
such a system could be built that doesn't depend on an architectural flaw of
some sort in email's design or implementation.
I'm actually quite eager to be proved wrong on this since it will necessarily
expand my knowledge of what email systems are capable of. But I require proof,
not the handwaving I've seen so far.
Luckily I think that an
acceptable solution can be found without having a debate about basic
CS theory.
I'm delighted to hear it.
> > More inline ...
> > On Aug 17, 2007, at 2:34 PM, Alexey Melnikov wrote:
> >
> >> Cullen, does the following address your DISCUSS?
> >>
> >> =============================
> >> In section 4.2, last paragraph:
> >>
> >> OLD:
> >> Implementations SHOULD take measures to implement loop control,
> >> possibly including adding headers to the message or counting
> Received
> >> headers. If an implementation detects a loop, it causes an error.
> >> NEW:
> >> Implementations SHOULD take measures to implement loop control,
> >> possibly including adding headers to the message or counting
> Received
> >> headers as specified in section 6.2 of [SMTP]. If an
> >> implementation detects a loop, it causes an error.
> >> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> >>
> >> Add to the end of section 4.2 two new paragraphs:
> >>
> >> Implementations SHOULD provide means of limiting the number of
> >> redirects a
> >> Sieve script can perform.
> >
> > Well if it was the number of redirects SHOULD be limited to one it
> > would do it but as it is - not sure I see how it helps.
>
> Cullen, I told you before, there is very strong WG consensus to allow
> implementations to use more than one.
>
> Please see
> <http://www.imc.org/ietf-mta-filters/mail-archive/msg03601.html> and
> <http://www.imc.org/ietf-mta-filters/mail-archive/msg03599.html>.
>
> Now, if you have another suggestion how to address your issue, I would
> like to hear it.
I have given a simple and easy way to address it that seemed to also
work for the use cases that people told me about (I certainly admit I
don't know all the case).
If memory serves, your suggested way to prevent it was to allow at most one
redirect operation to be done during the execution of a sieve script. And
you've been told that this is simply not acceptable - there are too many use
cases for forwarding email to two different places at once. In fact this is an
incredibly common thing for people to do for all sorts of legitimate reasons,
including but not limited to:
(1) Making messages accessible in multiple ways, e.g. send one copy to
my email account and another to my pager. Or voice mail. Or printer.
Or FAX.
(2) Secretaries who need copies of their boss's email.
(3) Maintaining multiple mailboxes during a service transition period. Or
two pagers.
(4) Making backup copies of mail to address reliability issues (IMO this is
not the best way to solve this problem but it is commonly done this way
regardless of what I think).
(5) Making copies of stuff for law enforcement use (garden variety
forwarding is a piss-poor way to implement this but it is nevertheless
something people do fairly often).
(6) Vacation-time forwarding of important messages to the "next tier" of
handlers.
We have two large banks as customers, both with thousands of employees. The
American one is very well known - anyone who isn't a complete hermit is
guaranteed to be familiar with it. They have a very elaborate email setup that
routes mail through various analysis, categorization, and compliance facilites.
The outcome of these operations are then assessed with various sieve scripts,
which then use redirect and various other tools to alter message routing. The
ability to redirect to multiple addresses plays an important role in all this.
The other bank is European (and may be a household name there for all I know)
and their setup is even more relevant. They have basically used Sieve to
implement an elaborate workflow system. Some of their scripts use redirect
10-20 times on a single message. The most interesting aspect of their setup is
that they have intentionally created loops all over the place. They use various
checks, some explicitly done in Sieve, some autogenerated in Sieve, and others
external to Sieve, to break the loops at exactly the right points. This usage
is way past what, say, .forward files can do. The proper functioning of this
setup is so important to them that no less than the CEO of the bank has been
known to "drop in" on technical discussions of various implementation details.
(And this is not hearsay - I'm speaking from direct personal experience.)
I could go on and give many more examples of use cases but hopefully you've
gotten the idea by now. The ability to autoforward to multiple addresses is an
essential feature - it has part of modern email effectively from the beginning
and without it Sieve simply doesn't have feature parity with other message
filtering facilities. In our case if we were to remove it our customers would
simply find a different vendor that doesn't impose such limits. As for setting
the default limit on redirect to 1, all that would accomplish for us is to keep
us all busy dealing with the resulting support calls.
However, let me be very clear - it is not
my job to find a solution that the WG likes to this.
It is, however, your job to impose reasonable requirements. And IMO you are not
being reasonable here.
I believe that
the IETF has clear consensus that it does not want to deploy
technology that could trivially be used for large scale DOS and
message amplification attacks with very little safeguards or
traceable ways of dealing with this.
This presupposes that there's a real risk here and that the necessary
safeguards are not in place. I don't believe either of these are true.
The fact is Sieve and numerous other autoforwarding mechanisms are already
widely deployed without the limits you think are necessary and curiously all of
these serious flaws you see aren't being exploited.
I dislike trotting out our own deployment statistics but it seems now is the
time for it. According various sources our product provides service for well
over 100 million mailboxes. A significant fraction of this total provides end
user access to set up sieves and our current default is to allow up to 32
redirects per sieve. As I pointed out in my original response, the number of
customers we've had that have reported problems with sieve redirect and have
needed to impose limits is exactly zero. And believe me when I say that our
customer base includes lots of people who aren't exactly shy about reporting
the least little thing that goes wrong.
Now my current judgement call is
that this is in that category and could cause harm to the internet.
But we're not dealing with a new protocol with zero operational experience here
where such judgement calls are our only means of assessing possible risk.
Rather, we're not only dealing with a protocol that has signifcant deployment
and operational experience, we're talking about a particular feature that's
been an integrall part of email for decades and is accessible in all sorts of
ways besides Sieve.
You can convince me I am wrong about that - or you could find a way
of mitigating and reducing this risk - I can think of several and I
have suggested the one that I think is most likely to be acceptable
to the WG
Given that limiting redirects to 1 is totally unacceptable I have no idea
what you are referring to here.
but I make no presumption that I would know what is the
best solution for this WG on this problem. I have made it clear what
the issues is, why I think a change is needed, this should not be hard.
I don't think it should be hard either, but the talking at cross purposes
continues.
So let me try one last time to cut through the misunderstandings.
First, nobody is claiming that autoforwarders cannot be used as an amplifying
component in various sorts of attacks. They can be used this way. This was true
for email decades before Sieve came along and it will continue to be true no
matter what we do in this document.
Second, nobody is claiming that script analysis can be used to prevent people
from abusing Sieve as part of such attacks. It simply cannot be done.
So, since such attacks are inherently possible in the present email
infrastructure no matter what we do or don't do in Sieve, the focus has to be
on detecting and stopping attacks. This is done by:
(1) Making sure infinite loops can be detected and stopped. The main risk is
that without comprehensive loop detection you can and will end up with
exponentially growing message loops. I've seen such situations
arise and create literally 10s of millions of messages in a very short
period of time.
Without a true loop the amplification potential of an autoforwarder web is
bounded by the number of autoforwarders in the web multipied by number of
redirects that are allowed per sieve. So the only way such a web can be used
effectively is if you have the means to inject an endless stream of messages
into it at some point. And that brings us to:
(2) Rate limit message submission. If true loops aren't possible something
somewhere has to act to generate the "signal" that is "amplified". This
sort of behavior can be detected and blocked.
(3) Administrative controls. The basic rule is don't allow users to access
functionality they don't need. If there's never a need to use redirect,
disable it entirely. If they only need to be able to do one redirect
per sieve, only allow that. If they only need to be able to redirect to
other users onsite, only allow that. If a class of messages exists that
aren't supposed to be redirected, check for them and yell if a redirect
is done. And so on. The list of possibilities here is very long.
(4) Auditing and tracking. The aforementioned European bank has a requirement
that every message carry a complete history of the redirection that was
performed. They also require that all of this be derivable from the logs.
And many of our other customers have similar requirements.
More generally, the days where email systems can get away without producing
comprehensive logs and audit trails ended a long time ago. I have no idea
what you're basing your assertions that such attacks would not be tracable
in modern email systems, but it runs absolutely contrary to all of my
recent experience.
Now, I will admit that the document doesn't cover a lot of this. But there's a
reason for that: Autofording to multiple address exists independent of Sieve
and as such is a general architectural issue for email, not one specific to
Sieve. It would be great if there was a document comparable to RFC 3834 for
autoforwarders but there isn't, and it is not within scope for this WG to
produce such a specification.
So what can we do? Well, I guess one option would be to try and make
the discussion of this a little more explicit in the document. How about
adding something like this to the security considerations?
Allowing a single script to redirect to multiple destinations can be
used as a means of amplifying the number of messages in an attack.
Moreover, if loop detection is not properly implemented it may be possible
to set up expontentially growing message loops. Acording, Sieve
implementations:
(1) MUST implement facilities to detect and break message loops. See
RFC 2821 section 6.2 for additional information on basic loop
detection strategies.
(2) MUST provide the means for administrators to limit the ability of
users to abuse redirect. In particular, it MUST be possible to
limit the number of redirects a script can perform. Additionally,
if no use cases exists for using redirect to to multiple destinations,
this limit SHOULD be set to 1. Additional limits, such
as the ability to restrict redirect to local users MAY also be
implemented.
(3) MUST provide facilities to log use of redirect in order to facilitate
tracking down abuse.
I didn't include rate limiting on the list for several reasons: (1) It's hard
to get right and naive attempts to implement it can be very dangerous. (2)
There's no consensus on what best practices for it are and hence any discussion
of it is likely to rathole.
I would also suggest getting rid of the discussion about sanity-checking since
this discussion seems to indicate it is open to serious misinterpretation.
Does any of this work for you? If it doesn't I'm frankly out of ideas for how
to resolve this.
Ned