The problem here is that the draft does not explain how it
deals with the cut and paste attack. I've specifically asked
about that and have been told yet again that I'm "reading
way too much into it" -- a non answer. With none of the body
included in a hash, a spammer can simply cut a valid
signature and append whatever spam to the body they
want. That's not good. If you counter this by putting some
or all of the body into the hash, the whole process looks
like the more general purpose solution (eg, IIM). As I've
said, I've tested IIM to see if it works against the bounce
reflection attack -- it does. The big question is how to
make this tradeoff against of hash survivability through
bouncers and the cut and paste attack. What I don't see is
why a completely different mechanism for this attack is
necessary.
Mike
David Woodhouse writes:
On Tue, 2004-09-07 at 11:33 -0400, John R Levine wrote:
[ Tony Finch ]
BATV is not a message data verification system. It simply allows you to
link a bounce to an original message sent by you. ...
[ Michael Thomas ]
If I as a spammer simply need to capture a *single* BATV
verification header for, oh say, aol.com and attach whatever
spam content I desire and bounce it through some dupe relay,
that is a *significant* problem.
I think you're reading way too much into BATV.
Indeed. Like John, I've been been using a scheme like BATV for a while.
We've been calling it 'Signed Envelope Sender', which was a term coined
by Meng Weng Wong when the idea was discussed on the spf-discuss mailing
list in February.
It doesn't give the recipient a 100% guarantee that the message really
did come from me, but it does _instantly_ stem the flood of backscatter.
The beauty of the scheme is that it is unilateral -- it doesn't require
any third party to upgrade to co-operate; you just stop accepting the
bounces to mail you didn't actually send. That in _itself_ is enough.
Of course, BATV _can_ be used to give a benefit to (potential)
recipients too. Those using SMTP callouts (no heckling please)
automatically get the benefit. It has also been suggested that the use
of a 'stunt DNS' server and the SPF-Classic/marid-mailfrom 'exists'
mechanism could be used to let potential recipients reject faked mail.
I think BATV has immediate benefits for the deploying user which would
be hard to achieve with any other mechanism.
Yes, it has some problems which I deem to be minor. First there's the
fact that some recipients (ezmlm mailing lists in particular) like a
constant envelope sender. To fix this, we can define a standard form for
the signature, and ask such recipients to strip the address back to its
original form before doing their checks. However it would be stupidly
naïve to assume that the whole world will upgrade to help us implement
any new scheme we come up with, so we can _also_ work around the problem
by using fixed address-signatures for certain 'problem recipients'.
Also there's the possibility of replay attacks. One possible answer is
to merely declare that the likelihood of these is low and that we hence
don't care -- the signed reverse-path is rarely made public since it's
changed by mailing lists and generally omitted by mailing list archives.
Also, the uptake of BATV (or indeed any scheme) will never be universal
and there will always be easier pickings. Certainly that's been my
answer for the last seven months; but maybe there are better answers
too.
One suggestion made recently has been to generate a hash of the message
body itself, and include that in the reverse-path. While body-signing
schemes at the RFC2822 level need extra complexity to deal with the
possibility that the message may be modified in transit (qv), this is
less true for a signature in the reverse-path. A simple md5sum of the
message could be included as part of a 'standard' BATV address format,
and the recipient could check the body of the message against that.
This wouldn't be as fragile as signatures tied to the RFC2822 identities
because the most common offender -- mailing lists adding footers and
stripping MIME parts -- is going to change the RFC2821 'MAIL FROM'
address anyway. And the other most common offenders -- the addition of a
pointless disclaimer or a free advert for some virus checking system --
can be done either at the sending site _before_ generating the md5sum,
or at the receiving site _after_ checking it.
It's an open question as to whether the extra complexity of including a
message digest is actually worth the benefit, or whether verification of
message content should be left to complementary schemes such as DK. But
the current BATV draft offers the choice of multiple 'public' address
signature schemes, so perhaps it would be sufficient to merely define a
public scheme including such a hash of the message, and permit the
implementing sites to choose whether to use that or a private scheme?
Another possibility is to include in the reverse-path not a hash of the
whole body, but only a hash of the DomainKeys header, in the case where
DK is used. Thus, BATV and DK would serve as an ideal complement to each
other.
(for DK please read 'your RFC2822 message signing system of choice'. I
haven't got that far... yet)
[ Not all the ideas above are my own, btw. Some discussion has taken
place in relative seclusion on a mailing list which was set up to
discuss 'SES' without polluting the SPF discussion list further. ]
--
dwmw2