spf-discuss
[Top] [All Lists]

RE: Security Paper on forgery bounce DDoS

2004-04-19 01:24:55
From: Greg Connor
Sent: Monday, April 19, 2004 1:07 AM


--"Stuart D. Gathman" <stuart(_at_)bmsi(_dot_)com> wrote:
8) SES gives senders who adopt it immediate protection from
bounce spam
while still accepting valid DSN's without anyone else adopting
anything. SPF+SRS requires wide adoption before achieving a
significant reduction in bounce spam.

On Sun, 18 Apr 2004, wayne wrote:
True, and this is the thing I like about SES.  When I get time, I may
well use David Woodhouse's Exim patches to implement SES on my
system.

--"Stuart D. Gathman" <stuart(_at_)bmsi(_dot_)com> wrote:
I am thinking about doing CBV only when there is no SPF record for the
claimed sending domain.  Does this sound like a reasonable policy?
It would encourage domains suffering from lots of CBV probes (with or
without SES) to publish SPF records.  I already do SES to prevent
bounce spam.


I would agree with you (and wayne) that SES is great for reducing bounce
spam.  And, if you're going to do CBV anyway, might as well skip it on
those that you can verify with SPF.  I think a "best case" scenario would
be to use both SPF and SES.  SES reduces incoming bounce spam
now, SPF pays
off more slowly, but is effective against other types of forgery
that don't
involve bounces.

I'm a bit late in commenting, but the following applies back to Seth's
original comment about SES+CBV...

Not at all.  I appreciate any and all comments.



I personally don't like the idea of SES+CBV because I don't like CBV in
general.  Just a personal preference.

Many knowledgeable people feel the same way about CBV.  However, does it
bother you more than SRS?  There is also a form of SES that does not require
CBV's, but it entails extra load on the recipient (see below).



Also, without something published in DNS that says "accept only signed
return paths" there is nothing to really stop others from spoofing your
domain in their spam...

That is an interesting point.  When there is a signed return-path, it is
obvious that the sender invites a CBV to verify it.  With an unsigned
return-path, the recipient doesn't know what the sender's preference is with
regard to CBV's.  However, if the recipient of a message with a (forged)
unsigned return-path does a CBV and the domain happens to sign all its
outgoing mail, they would get a fail result.  A CBV to a domain that does
not sign its outgoing messages would yield a positive result that doesn't
mean anything, which is the equivalent of a domain that does not publish an
SPF record.

A minority of mailers already do CBV's (no SES) as an additional qualifier
before accepting a message.  This irritates some people, but I can see the
justification for their position:  some people on principle don't want to
accept mail from a system that won't accept a DSN back.  On the other hand,
some people seem to think that a CBV is a hostile act.  It's obviously a
controversial mechanism.

I did mention in a response to George Mitchell's question that it is
possible to do SES without CBV's using information published in the DNS.
This would be an asymmetric crypto system where the sender signs the return
path with a private key and the recipient verifies the return path with a
public key from the DNS.  I don't particularly like the extra overhead this
puts on the recipient, but that is my own preference.  If people will not
accept a CBV-based system, perhaps the asymmetric crypto option would be
acceptable?  I'd be interested if people think that SES would be more
appealing if it used an asymmetric crypto cookie for verification by each
node rather than a one-way hash and a CBV.

My interest in SES really has three motivations:

1) I think that SRS creates enough serious problems to make it worth looking
at alternate schemes that don't require such extreme measures.

2) SPF checks are done at each hop in the message path.  Each subsequent
recipient must assume that the previous system did SPF checks on the
incoming message and got acceptable results.  The original SPF status of
message can become unclear by the time it reaches the final recipient in
much the same way as the old "telephone game" corrupted verbal messages.
Because every site will take different actions with each SPF result (the
standard does not even require sites to reject a message based on an SPF
fail result), and sites will unfortunately differ in their interpretation of
an SPF record, the final recipient can't have very much confidence in the
SPF checks done previously.  For a system that purports to verify the
original sending MTA of a message, this is a very serious problem, though
SPF is otherwise a brilliant idea.

In order to solve this problem, there needs to be some way for the final
recipient (and intermediate nodes, as well) to verify the return path
independently and according to its own policy.  Whether the mechanism is via
CBV, something published in DNS or some other method, I believe that is a
requirement for any rational anti-forgery system.  To permit this form of
operation, something has to travel unchanged from the sender through the
entire message path.  This would kill two birds with one stone: allowing
each system to verify the message return path to its own satisfaction and
avoiding the need for SRS.

3) I like the nifty "side effect" of being able to reject bounce spam while
still accepting valid DSN's.  There seems to be little disagreement on this.

there are still dozens of valid mailing addresses
that accept mail and must therefore accept CBV requests... e.g. even if
<gconnor(_at_)nekodojo(_dot_)org> doesn't accept direct mail (which would 
play heck
with my normal replies, not to mention making me less reachable
all around)
then at the very least <postmaster(_at_)nekodojo(_dot_)org> must accept mail, 
so
SES+CBV by itself would not stop forged messages claiming to be from a
valid (but not signed) return address.  And, if I'm going to publish
something in DNS, I would rather just publish an SPF record.

SES and SPF really do attempt to do the same thing.  For regular (non-null
envelope sender) messages, neither method is effective in preventing
forgeries if the domain owner does nothing.  If the domain owner neither
puts an SES signature in the return path nor publishes an SPF record, you
really have no information to go on.  Both systems need some input from the
domain owner to function.

--

Seth Goodman