[Top] [All Lists]

Re: Suggested changes to address Cullen's DISCUSS on draft-ietf-sieve-3028bis-12.txt

2007-08-29 14:22:40

Ned, this is a very helpful email on moving things forward - thanks. If' you get to the bottom of this email, I would be fine with a very minor variant of what you are suggesting and I think it meets the use cases you brought and god to discuss changes if it does not resolve others that were not brought up.

On Aug 25, 2007, at 3:59 PM, Ned Freed wrote:

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.

Uh  .. the text that say
   It is equally important that implementations sanity-check the user's
   scripts, and not allow users to create on-demand mailbombs.  For
   instance, an implementation that allows a user to redirect a message
multiple times might also allow a user to create a mailbomb triggered
   by mail from a specific user.

but ignore this - lets move ton to how to fix instead of why I thought the draft suggested something 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.
Uh - you sure. I'm not aware how to make gmail go to multiple system which is of course the important one because the others systems have relationships with you and other ways to secure things by causing bad consequences for you if you abuse the system. But again, let's get to how to fix it which I think you and I are on roughly the same page.

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

Yes agree with all your analysis here/

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

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

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.

Once again, I have only said I suspect it is turning complete not that I have proof of such. Anyway, we both agree this is irrelevant to resolving the problem.

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

Well, what I have in my notes from the prague meeting was "Told them I was OK with SHOULD not redirect to more than one location outside the domain". We may have different ideas about what domain means but roughly I would mean administrative domain - certainly I would call an enterprise or large bank one domain even thought they might have separate DNS domain names for different locations or something. You might use the term "onsite" where I used domain.

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.

Actually, I have received very little comment on if this is acceptable or not. I have mostly recieved something that loosely translated to "the WG disagrees with your discuss". I would be very happy to talk what my concerns are and have folks figure out if their is a solution that addresses them and still meets the bulk of users needs.

In fact this is an
incredibly common thing for people to do for all sorts of legitimate reasons,
including but not limited to:

I suspect what I had proposed meets all these use case but don't claim to really know. Glad to be educated.

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

(uh, yah, laughing about how well this will meet some US Law enforcement requirements :-)

(6) Vacation-time forwarding of important messages to the "next tier" of

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.

I'm not surprised - this all seems very consistent with my discussions to these types of folks. I assume you also have the discussions with the people like Yahoo, MSN, gmail, around the policies they put in place to stop their servers from being used in DOS attacks? I know I have been dragged into a few theses - can you provide some insight around policies there?

In understand that different things are used in different times - the goal of this document should be to produce something where the Security considerations are good enough not to cause serious harm.

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.

The solution would be discussion around understanding a set of reasonable requirements and feasible designs.

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.

So far no one as sent me any information arguing these are not 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.
Sure - and clearly if it is not a problem, it is stopped somehow, I'm asking the Security section to provide some advice about how this is all stopped.

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

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.
yet somehow widespread message amplification attacks from email are mitigated to an currently acceptable level.

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.
agreed - let's make sure the draft does not suggest people do it

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.

Certainly agree with you in enterprise case but in a public provider such as yahoo, sure they have logs but they may not have any way to tying that to an actually human associated with the account.

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.

I really liked the above analysis - it's the most information I have received on this thread since I first read this document. Thank you.

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?

This is great - few bits inline below...

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

(1) MUST implement facilities to detect and break message loops. See
       RFC 2821 section 6.2 for additional information on basic loop
       detection strategies.
My discuss did not ask for this but it certainly seems like a good idea.

(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
We are very close here. If you changed the "Additionally if no use cases exists for using redirect to to multiple destinations this limit SHOULD be set to 1." to "Scripts SHOULD be limited to at most one redirect that is not 'onsite'". And define onsite somewhere. I'd point out that this is a SHOULD not a MUST and that it could be ignored if people understood the security implications of what they were about to do. This could also possibly be coupled with idea after next point to explicitly allow multiple redirects in some cases.

(3) MUST provide facilities to log use of redirect in order to facilitate
       tracking down abuse.
I would ask if this mean that they MUST know what human the script was associated with. If yes, it is way beyond what I am asking for and if no then hard to see how it helps. When I mentioned months ago I could imagine many ways to solve this, coupling this type of thing to the ability to do more than one redirect was one of the things that seemed like a possible solution (and corresponds to my understanding of at least some current deployments).

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.
This seems extremely close to fully resolving it. I think your suggestions are great and glad to have a dialog that suggests something to solve the issue.