From: Shevek
Sent: Friday, June 04, 2004 5:44 AM
On Fri, 4 Jun 2004, Stuart D. Gathman wrote:
On Thu, 3 Jun 2004, Michael R. Brumm wrote:
Finally, I've thought a lot about SRS vs. SUBMITTER in the
past few days.
SRS:
ugly
not exploitable
requires upgrading only the MTAs which forward
SUBMITTER:
pretty
bounce forgery is exploitable
requires upgrading ALL MTA which wants to receive a forward
(much larger
pool)
You forgot:
Resurrecting Deprecated Reverse Source Path:
pretty
bounce forgery is exploitable (fixable with SES, btw. See
suggestion for
validating SES via DNS instead of CBV.)
requires upgrading (or downgrading :-) only the MTAs which forward
You forgot:
exploitable.
We spent considerable time and effort going over the replay attack scenarios
on this list at Meng's behest. The consensus was:
1) Replay attacks are limited to a small class of promiscuous sending
accounts that may communicate directly with spammers. It is not an issue
for the great majority of users.
2) For those few accounts that are susceptible, replay attacks can be foiled
by a variety of methods: extended precision timestamps that are unique per
message and salt the hash, automatic invalidation of hash+timestamp
combinations that are used in a replay attack, per-user hash keys to avoid
compromising more than a single account, longer hash to make cracking more
expensive, etc. It is feasible to protect against replays by signing just
the return-path.
3) Mailing lists do not preserve the original return-path, so that is not a
source of signed addresses.
--
Seth Goodman