[Top] [All Lists]

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

2007-08-31 11:51:03

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

Yes, as a matter of fact I am sure. I try very hard not to make assertions
without the facts to back them up.

I'm not aware how to make gmail go to multiple system

It's trivial. Hit the settings tab at the top right and then create two
filters. Use whatever critera you like and have one that forwards to address A
and the other to address B.  Before I included gmail in my response I tested
this with two non-gmail accounts I have elsewhere and gmail happily forwarded a
test message to both. No warnings, no problems, just two copies of the mail. I
just checked my account again just now and the both forwards are still in place
and working. Here's approximately what my settings page has to say about it:

 The following filters are applied to all incoming mail:                
 Matches: subject: vvv
 Do this: Forward to xxx(_dot_)xxx(_at_)yyy(_dot_)yyy

 Matches: subject: vvv www
 Do this: Forward to zzz(_dot_)zzz(_at_)aaa(_dot_)aaa

I can't really talk about the specific ISPs we have as customers and their
policies, but I can assure you gmail is not alone in offering this capability
to their users. To the extent offerings differ, the difference seems to be
whether or not users are allowed to configure custom filters at all, not
whether or not setups that allow custom filtering configuration can forward.
Hotmail, for example, effectively doesn't offer custom filter settings, so it
is hardly surprising that they don't offer forwarding.

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.

I don't believe this is as much of a difference as you seem to think. Quite a
few of the cases of mailbombing I've seen have been disgruntled employees and
the like attacking their own company's systems. (AFAIK none of them involved
the use of sieve redirect, but that's really beside the point.) Apparently
nothing says "I quit" quite like a mailbox with 10 million pieces of hate mail
in it.

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

And I responded that I think that goes too far and isn't reasonable. In
particular, a SHOULD that fails to take into account that there are legitimate
use-cases for mutlple redirects makes the entire specification look incompetent
and serves to weaken the effectiveness of all the other advice we give.

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.

I don't think the restriction to a single domain, regardless of what domain
means, accomplishes nearly as much as you seem to think it does. Again, to the
extent mailbombing is an issue, in my experience it's as much of one within an
ADMD as outside of it. Perhaps more.

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

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

Then there has been a disconnect getting WG comments back to you. Several
comments were in fact made, including but not limited to one from me.

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

OK, let's go down the list and see how ADMD restrictions fare:

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

A very common case is for pager, fax, or voice mail services to be outsourced
to an external service provider. Often as not different people in the org will
use different providers for this stuff. This is especially true if we're
talking about a hosted setup. ADMD restriction cannot possibly work here.

> (2) Secretaries who need copies of their boss's email.

ADMD restriction are mostly compatible with this use-case.

> (3) Maintaining multiple mailboxes during a service transition
> period. Or two pagers.

This would depend on the nature of the transition. I've seen transitions to
another ADMD as well as transitions within an ADMD. Domain restrictions are
problematic in this case.

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

In many cases the entire point of doing this sort of thing, especially at the
user level, is to get a copy of your mail to a place that has separate
administative controls. ADMD restrictions would be hugely problematic
for this use-case.

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

I can't get into details, but the truly amazing thing is that I've seen
situations where law enforcement _insisted_ on it being done this way  even
when a technically superior solution was available. (I'm actually writing a
response to a proposal that's basically a variant of this idea in  another

I don't actually know if the cases where this has been done involve forwarding
outside the ADMD or not. (To be honest, I try very hard to learn as little
about the operational details of interception activities as I possibly can.)
But given the complete lack of clue needed to even consider using this approach
I would not be at all surprised if such forwarding has been done in this case.

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

This is usually done inside the ADMD but not always.

Tallying up, restricting autforwarding by domain didn't fare so well against
this list of use-cases. So we're talking about a mechanism that is ineffective
against a significant subset of actual attacks as well as being incompatible
with a lot of completely legitimate things people like to do.

Yet another problem with domain restrictions is that it is easy for them to
turn into a violation of the least astonishment principle. ADMD boundaries can
be complex - I've seen setups that consider thousands or tens of thousands of
domains as local - and asking users to understand complex boundaries is in
effect asking for a lot of support calls. And SPs will do almost anything to
lessen the number of support calls they get.


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?

The people I talk to tend to be large ISPs rather than these sorts of SPs, but
yes, we talk about DOS attacks a fair amount. However, the issue of the ISPs
own infrastructure being used in the ways you envision for DOS attacks has
almsot never come up, for the simple reason that it is not a significant issue
for them.

I know I have been dragged into a few theses - can  you
provide some insight around policies there?

OK, let's look at email DOS attacks in a bit more detail. Let's start with what
sounds like a silly question: What does an MTA do? The answer, of course, is
that it transfers messages around. It follows that if an MTA is good at its job
it has to be able to accept and process messages fairly quickly. And this is in
fact the case: It isn't at all difficult to get performance of 50
messages/second on a single box. With a little more effort you can kick things
up into the 500 messages/second realm (the main issue at this point is spam and
virus scanning performance) and MTAs have been built that can handle well over
2000 messages/second (at this point threads and filesystem performance become
the bottleneck, requiring a bunch of exotic tricks to deal with).

MTAs are also built defensively, and the primary defensive stategy is to try
and stop the bad stuff as close to the security perimeter as possible. The
further in stuff gets the more resources have to be expended dealing with it.
For example, when a user goes seriously over quota the best thing to do is turn
back mail with a 4yz (temporary) error, not accept it and hold it until they go
under quota again. Various rate limiting strategies are useful here as well and
in practice are widely deployed. So unless your attack has both a distributed
source and destination there's a very good chance it will be quickly detected
and blocked.

The bottom line is that modern MTAs are very good at handling lots legitimate
SMTP transactions and take all sorts of steps to prevent themselves from being
overwhelmed by too many of them. So attacking the email infrastructure by
performing lots of real transactions is in effect a frontal attack against the
most heavily fortified part of the entire system. This is not a recipe for

So if frontal attacks don't work very well, what does? What we commonly see are
attacks on various server resources: Connections, threads, processes, memory
and disk. If an attacker can consume enough of some resource they can bring the
servers down or at least make them very slow. For example, one attack we saw a
while back was to send an infinitely long message - some MTAs buffer messages
in memory and done right this could consume all available swap space and hang
the server. Or there's the trick of opening lots of connections but never
sending any data. Or stopping in the middle of the transaction. (This one is
apparently popular right now - I have no idea why.) Or sending commands R E A L
L Y  S L O W L Y. Or attacking the network stack with malformed packets,
incomplete TCP exchanges, and so on. Or simply overwhelming the network itself
with data. Or causing the MTA to overlaod some  other service, e.g. kill the
directory server by sending lots of RCPT TOs and forcing lots of lookups. Or
exploiting some known flaw in a particular implementation, e.g. blowing a vital
cache by doing something to invalidate its content. The list is long, and if
the attacker is highly distributed some of these are very difficult to defend

But now let's consider where autoforwarders fit into this attack tree. First of
all, since email is store and forward you cannot get an autoforwarder to
perform anything but an actual transaction, corresponding to a direct frontal
attack - exactly the attack MTAs are best at preventing. Even worse (for the
attacker), autforwarders don't provide an attacker with much flexibility in
terms of either distributing either the source or destination of the attack:
Automating account and filter creation is in most cases difficult if not
impossible, making the task of getting enough autoforwarders in place very time
consuming and error prone, and most autoforwarders, including Sieve redirect,
can only forward to a fixed set of destinations - the redirection cannot go to
an address that's pulled out of the message itself. (The sieve variables
extension changes this, but the topic at hand is what's possible in the Sieve
base specification, not what some extension allows.) Finally, the people who
offer autoforwarding as part of their service are as a general rule not morons
and will probably notice if a large volume of email starts coming in only to be
forwarded right back out.

The bottom line is that, your beliefs to the contrary notwithstanding,
autoforwarders just aren't that interesting of a tool for attackers. This has
been largely true throughout the history of email, and in the present world of
botnets it is more true than ever. The folks at Cloudmark (who know far more
about the attack landscape than I do) told me a couple of weeks ago that the
botnets out there are now so large that devastating results can be had even if
each infected system only sends out 5-6 messages a day. Given this why would
any attacker even bother making autoforwarders part of their attack toolkit?

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

Say what? My responses have contained exactly this sort of information and
argument. And AFAICT you have yet to effectively refute a single point I have

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

Leaving aside that this is a fairly significant change in position on your
part, the problem with this is that your reasoning rests on an unwarranted
assumption: That the reason it is not a problem is because people have taken
specific steps to prevent autoforwarder abuse. The fact of the matter is they
haven't done this. What has happened instead is that the myriad of other
measures people have taken to prevent attacks on the email infrastructure have
collectively managed to make autoforwarders a fairly uninteresting tool for

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

Yes, because the measures people take to defend against other, far more
pernicious attacks end up defending against autoforwarders vicariously.
Defending against mail loops, for example, does more to limit the effectiveness
of autoforwarders as an attack mechanism than any other step you can take. But
if you don't have reasonable loop detection in place you will quickly find that
autoforwarders are the least of your problems.

> 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

I have no problem with that.

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

But even if they had the information they still aren't going to go after most
abusers - law enforcement could not care less about this stuff and a civil suit
is way too much trouble for way too little gain. All they're going to do  is
shut down the account.

BTW, the same is often true in the enterprise case: If some guy uses a mailbomb
to say "I quit" the odds are pretty good the company will simply clean up the
mess and move on.

In any case, the point of having good logs is to be able to identify and stop
bad behavior. Catching and punishing the person responsible is a whole
different matter.

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

My discuss did not ask for this but it certainly seems like a good idea.

Alexey already pointed out that you did in fact ask for this.

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

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.

My problem with this is that "onsite" or "within the domain" or whatever should
not be conflated with limiting the extent to which users are allowed to use
redirect. I actually think you have substantially weakened the impact of this
guidance by over-emphasizing domain restrictions.

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

On the contrary, this is arguably the most useful advice we have to offer. Real
time as well as offline analysis of logs is in practice one of the primary
tools that's used to find and eliminate email abuse. We actually spend at least
as much time advising our large ISP customers on how to do this more
effectively than we do on how to set up rate limiting or any other sort of
defense. (And as I mentioned previously, our ISP customers have demonstrated no
interest whatsoever in administrative limits on redirect. And we'd know because
it turns out the limit option wasn't documented.)

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

In conclusion, Alexey has proposed new text in a separate messagage which
I find completely acceptable. Please take a look at that and let's see
where we are.