[Top] [All Lists]

[Asrg] Re: BATV and SES - was forged bounces

2005-06-04 10:35:54
BATV doesn't require the sending host to remember anything about
messages it's sent.  It uses signatures.

So does SES. But what happens is that if you just encrypt bounce address
this is visible on the net and the address can be reused (replay attack).
The partial solution to that is to include timestamp and change keys 
often, but that does not eliminate it - just makes it more difficult to
organize it. ...

So in the end you're left with option of using message body to create 
unique bounce-address signature at the time email is sent but also have
to keep that signature in your database to be able to validate it. So
why bother with cryptography then? It might as well be that you create
long random number (alphanumeric random) and use that for each bounce
address and keep that in database.

This completely misrepresents the purpose and function of BATV.  I
know that we've had this exact same exchange at least once before, and
I really wish you would cut it out.

BATV does one thing -- it defends against bounce blowback from mail
forgery.  It does not purport to be an all-purpose anti-spam or
anti-forgery technique.

The point of BATV is to ensure that whoever sent you a bounce had a
message from you in hand when it sent the bounce.  That's all it does.
It does that by adding a one-way hash of the bounce mailbox and domain
to the bounce address that the original sending domain can check.  As
we've noted, the MTA needs no per-message state to generate or check
the hash.

People say "it doesn't defend against replay."  Well, duh, it doesn't
even try.  There's two reasons for that.  One is that replay isn't a
problem and isn't likely to be.  It is exceedingly rare to see a
deliberately forged bounce, and it is hard to see a plausible scenario
in which bad guys would want to forge them, other than as DOS attacks
for which they already have lots of other techniques.  The other is
that even if it seemed desirable to do so, you can't, since there is
no way to tell how many bounces a message should legitimately get.
You can't tell whether a message is going to one person's mailbox or
to an exploder that will remail it to a thousand people.  My version
of BATV has a timestamp which I added mostly so that if someone
scrapes old bounce addresses off web mail archives, BATV will reject
them, but I have seen so few BATV failures due to expired timestamps
that I'm not sure I would put in the timestamp if I were doing it

We have contemplated one minor extension. Once the DK signature scheme
settles down, we might do a version of BATV that uses the DK key to
create a remotely checkable version of the signature.  There's still
no per-message state, and it's only signing the bounce address, but
this allows as an optimization that a remote MTA could check and
decline to generate the bounce instead of the original MTA rejecting
it.  This is a fairly minor optimization, since the current scheme
rejects bad bounces very efficiently.  The PC where lives
rejects 400,000 bounces on a bad day, without noticably increasing its

SES attempts to extend a BATV-like system to an all purpose
anti-forgery and/or message validation scheme, which fails for all of
the reasons that William mentioned and more.  So we're not going to do
that.  If you want to prevent "too many" deliveries, don't bother.  If
you want message body signatures, use DK (or DKIIM or whatever it is
now.)  If you want to defend against forgery bounces, use BATV.  If
you want to do both, use both, but please don't waste your time and
ours discovering yet again that one combined scheme won't solve both


Asrg mailing list