Arnt Gulbrandsen <arnt(_at_)gulbrandsen(_dot_)priv(_dot_)no> wrote:
Dave Crocker writes:
<http://brandenburg.com/specifications/draft-crocker-marid-batv-00-06dc.html>
There must be something I've missed. Doesn't the following attack work?
1. Prepare message to be sent in some victim's name.
2. Send the victim some mail calculated to get a response.
3. Wait for the victim's response.
4. Quickly use the (opaque) localpart from step 3 to send the message
from step 1.
Disclaimer: Though I have been corresponding with Dave, I know no more
about this than Dave already posted.
Does that "attack" "work"? What do you mean by "work"?
If by "work" you mean "pass the valid-bounce-address test", most likely
it will.
OTOH, if you mean "succeed in joe-jobbing the victim", I see no reason
to expect it will.
Bounce Address Tag Validation (BATV) generates a local-part meaningful
only to the domain that generated it. AFAICT, it must be used verbatim
in the RFC2821-RCPT-TO field, and only a MTA within that domain can
translate it back into a username for delivery.
Since it is designed (by "signing" "a hash of the address and time-
varying information") to resemble a one-time key, it seems unlikely
that a validation process would be programmed so as to pass many copies
back to the victim.
Rather, such an occurrence would signal an abuse event, where I would
expect bounced headers to be collected and give pretty clear evidence
of where the abuse originated.
Understand, this is intended only to indicate that the bounce address
is "valid", not to make any statement whatsoever about the message
content.
====
I'd also like to say that, with respect to my "40% solution", I'd be
happy to see this -- or any other reasonable validation method -- in
place of the queries I detailed for the purpose of validating MAIL-FROM.
Whatever the output of this WG is, I would hope we choose a modular
design where different "validation" tasks can be performed differently.
For example, Yahoo's "DomainKeys" proposal shows promise for validating
that the message indeed came "From" where it appears to be from, though
not in its first-draft form (IMHO). It seems entirely reasonable for
receiving MTAs to verify that way when appropriate.
After all, we shouldn't expect everyone to throw out their current
anti-spam measures and suddenly adopt our standard...
--
John Leslie <john(_at_)jlc(_dot_)net>