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.
With whitelisting, you can either pull that domain out of your whitelist
yourself, or you can use blacklists--presumably an outside RBL-type
blacklist that tracks that sort of thing.
With SRS, since you're implicitly trusting all SRS'd addresses that pass
SPF tests, you can only depend on blacklists.
Either way, you have to tell your machine, one way or another, not to
accept mail from the compromised forwarder, though whitelisting allows
you one more way to go about it.
That requires a huge infrastructure change at _every_ receiver site
instead of the far fewer forwarder sites. An enormous number of aol
users have their mail forwarded from places like @acm.org or
@alma.mader.edu. That would mean that aol would need to implement
per-user trust lists -- and the users would need to be educated.
Mostly a mere implementation detail. :-)
When a user selects to have their mail filtered on the basis of SPF
tests, AOL could have the default options to filter on the basis of
their internal trusted-forwarder list. (equivalent to an
"include:/etc/default-trusted-forwarders")
On the other hand, no users need to be educated if aol were to say:
forwarders don't use aol.com in the envelope sender, if you are
resending mail, take responsibility over the return path or expect it
to be rejected.
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.)
User/admin education:
o With whitelists, if a forward is being rejected, recipients can
whitelist that forwarder/address.
o With SRS and without whitelists, forwarders must implement SRS in
order for forwarded mail to be accepted. The potential recipients
have no control over the fact that the forwards will be rejected.
o Of course in both cases, rejected mail should immediately alert
the sender to the existence of a problem, so I'm not worried about
a sender not being aware of a problem, but rather the recipient not
being able to do much about it, (other than turning off SPF
checks.)
In the case of SRS, error messages could point the Sender to
information discussing SRS, and the fact that the forwarding
machine needs to implement it.
In the case of whitelists, error messages could point the Sender
to information suggesting that he ask the recipient to whitelist
that specific forwarder.
Ease of use and promotion:
o Whitelisting: Users understand that to forward mail, they must
specify who to forward the mail to. Now they simply need to
specify who to accept forwards *from*. Whitelisting is transparent
and relatively easily tested for correctness.
o SRS: Much harder to explain the need to users and, uhm,
recalcitrant email admins, requires more configuration for
admins, shared secrets between machines, and is yet one more
thing for admins to have to "get right" while still being able
to be misconfigured in a way that "seems right", (and thus
seeming to be working both correctly and securely.)
--
Mark Shewmaker
mark(_at_)primefactor(_dot_)com