RE: CBV

> From: Stuart D. Gathman
> Sent: Friday, May 07, 2004 2:22 PM
>
>
> On Fri, 7 May 2004, Seth Goodman wrote:
>
> > > > The key problems with SES seem to be EITHER:
> > > >
> > > > a) If a spammer gets hold of an SES source address, he has a
> > > > free ticket
> > > > to spam people using replay
> > >
> > > In conjuction with SPF, an SES or SRS source address only allows
> > > the spammer
> > > to spam 1 particular recipient for a limited time via a forged
> > > bounce.  An SES
> > > source is not a general relay ticket.  It is true that without SPF,
> > > general spam victims that only check CBV will for a limited
> > > time be tricked into thinking the sender is genuine.
> >
> > That's the vulnerability that we attempted to address by incorporating a
> > body hash in the MAIL FROM:.  The recipient can detect that the message
> > content does not belong with that MAIL FROM: and can reject the message,
> > albeit at the end of DATA.
>
> If I have to go through the DATA phase, there is no clear advantage to the
> SPF/SES scheme over bayesian filtering.  I really really don't
> want SES to
> have anything to do with the DATA phase.  I am fine with additional
> signatures for messages headers and body contained in some message
> header.  I.e., if you need to get the message DATA anyway, you
> might as well
> store the signature in the DATA, and not have to worry about
> local-part size
> limits and crud.

Nobody wants this, but there is a vulnerability to replay attacks.  Maybe
we've given it too much airtime, since the vulnerability only really exists
for promiscuous sales type accounts that send mail to anyone who asks.  For
regular email accounts, if you don't send mail directly to spammers, you
won't get your signature harvested.  Just as is the case with SRS-signed
addresses and Bcc: headers, the receiving MTA is expected to strip out those
things and not pass them on to the MUA's.  This is also true for mailing
lists and web archivers.  Just like it is today, don't send mail to spammers
unless you want spam, joe-jobs and grief.

The reason the body hash can't be stored in with the data is that what we
are trying to foil is a replay attack.  Someone harvests your SES-signed
address and uses it to send new message content purporting it is from you.
Since the CBV will pass, this is a vulnerability, though only for certain
types of accounts.

Despite the need to go through the DATA phase if the CBV checks out, this is
still a lot better than Bayesian filtering, which I currently use and am a
great fan of.  First of all, it detects forgeries with no false positives,
no false negatives, no per-user databases, no user intervention and it takes
a lot fewer CPU cycles.  A CBV pass followed by a body hash validation
doesn't tell you that the message isn't spam.  It only tells you that it was
sent by the party in the return path, but it does so with a very high degree
of confidence, much higher than with SPF+SRS.  Because of this, an SES pass
plus a listing on a sender whitelist means you can accept the message with
no further checks.  For non-whitelisted senders, or senders who do not sign
their outgoing mail, you will still need to run the Bayesian filters.

FWIW, the body hash is not all that bad, though I fundamentally dislike
anything after DATA, just as you do.  You still do the CBV before data, and
that should stop most forgeries.  The body hash is only used to make sure
that the MAIL FROM: is not a replay of a harvested address with a new
message attached.  If you detect that the message content does not match the
hash in MAIL FROM:, you would have to reject at the end of DATA, which is
distasteful to many of us.  The simple fact that the body hash is there
would make it useless for anyone else to harvest a SES-signed MAIL FROM: and
use it to joe-job you.  That won't stop them, just like publishing an SPF
record does not stop anyone from joe-jobbing you, but as it becomes less
effective, it will be attempted less.

I would like to find a better way to deal with this vulnerability,
preferably one that did not require a database at the sending end.  Another
possibility is to recognize that the problem only exists for a small number
of promiscuous accounts.  We could provide the option for them to add a
database key to their MAIL FROM: and be prepared to invalidate that key if
someone perpetrates a joe-job using a harvested address.  Everyone else
would not have to go to this trouble since they don't send mail to spammers.
This isn't a perfect solution, but I'm just thinking out loud.

>
> However, here is an idea (which has probably been tossed out before
> but I missed it).  You could have the SES signature cover the recipient.
> Then the spammer would only be able to spam himself.  The drawback is
> that for multiple recipients, the signature would be different
> for each one,
> possibly requiring extra copies of the message.
>
> The CBV would work with the recipient sending the recipient as MAIL FROM
> and the sender as RCPT TO.
>
> You could avoid copying the message for multiple recipients by creating
> a database record listing all the recipients for each message,
> and encoding a
> key to that record in the SES.


This particular one hasn't been brought up before, and it's very clever.
The only difficulty is that recipient addresses change when they go through
forwarding hops and the sender has no way of knowing what those new
addresses are.  I can't think of a way around this particular limitation,
but if you can, it would be a much better way to avoid replay attacks.

--

Seth Goodman