On Apr 22, 2004, at 3:34 AM, Mark Shewmaker wrote:
On Thu, 2004-04-22 at 00:52, Theo Schlossnagle wrote:
How do we handle the case when trusted forward is compromised?
I see no conceptual difference on the necessary response of admins or
users when a forwarding domain they had trusted becomes compromised if
comparing between whitelisting and SRS.
I wasn't intending to compare the difference between the responses of
admins and users. I was eluding to the difference between reactions to
a "trusted forwarder" being compromised and "just another forwarder"
being compromised. And, they are different.
I think a bigger difference is the failure modes.
Compromised forwarders:
o With whitelists, a compromised forwarder can only affect those who
have trusted the forwarder, (unless the forwarder appears on a
blocklist the recipient uses.)
o With SRS, a compromised forwarder can affect everyone, (unless the
forwarder appears on a blocklist the recipient uses.)
These are apples and oranges. The results of these compromises have
entirely different security implications. A forwarder using SRS was
granted no rights (or trust) by you and thus those rights can't be
abused. A trusted forwarder who is compromised inherently gains the
advantage of whatever trust was awards to that forwarder.
These solutions need to be widespread to work, so "only those who have
trusted a forwarder" will, hopefully, be a huge list of people. And
quite dynamic from small site to small site. It is tough to track and
each admin on each site must be aware of the integrity of each
forwarder they trust -- that is a lot to ask. All the while, the trust
that was award to that forwarder was to use _any_ domain name in their
return path -- the trust is that they won't use it fraudulently.
In the second case, the forwarder was never awarded these rights.
They have the same trust (SPF policy enforcement) that every other site
in the world has. When they are compromised there are no award trusts
to exploit.
The Internet is an untrusting place. When developing algorithms and
policies we _must_ not step in the same holes previous people have
stepped in. Algorithms, protocols, and policies must be designed with
the assumption that there will be byzantine parties and that attacks
will be performed on them. The more money there is to be gained by
attacking, the more sophisticated and effective the attacks will be.
There is a lot of money in spam. It's not a pretty picture.
SPF is designed to prevent fraud. Forwarders use a technique that is
used to commit said fraud. It is the _technique_ that is a problem and
for an effective system to emerge from all this the techniques that can
be used for fraud must be rendered useless.
Now to disclaim my rant. I don't think SPF is the best thing since
sliced bread. It will not solve the worlds SPAM problems. It performs
one simple task and because of this narrow focus has a _chance_ to do
it well. The whole concept of trusted forwarders threatens to damage
the correctness of the approach.
// Theo Schlossnagle
// Principal Engineer -- http://www.omniti.com/~jesus/
// Postal Engine -- http://www.postalengine.com/
// Ecelerity: fastest MTA on Earth