Just to be clear, I'm not trying to dump on the authors
here, but more to point out that this problem is very likely
a second harmonic of the primary problem -- forgery. And it
almost certainly has all of the requirements to deal with
the primary problem and quite likely adds more. Fleshing out
the unique requirements for the bounce reflection attack
from the simple forgery attack would be an extremely useful
exercise IMO.
Mike
Michael Thomas writes:
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