spf-discuss
[Top] [All Lists]

RE: SPF-compliant phishing?

2004-09-15 13:10:51
From: Rik van Riel
Sent: Wednesday, September 15, 2004 12:08 PM


On Wed, 15 Sep 2004, David Woodhouse wrote:

The example which really interests me is #1. Forgive me,
I'll repeat it:

  MAIL
FROM:<SRS0+xx+yy+example(_dot_)com+joeuser(_at_)pentafluge(_dot_)srs(_dot_)infradead(_dot_)org>
and
  Received: from [2002:c1ed:8229:10:2c0:f0ff:fe31:e18] (helo=joeslaptop)
     by pentafluge.infradead.org with esmtpsa id 1C7Ej2-0008II-SZ;
     Tue, 14 Sep 2004 15:56:09 +0100
  From: <joeuser(_at_)example(_dot_)com>

Now who can tell me if this really came from Joe or not?

How can we even tell whether it really came from example.com at all ?

Unless I overlook some big things, it would appear to me that SRS
could just be the perfect forgery mechanism ...

You're not overlooking anything.  Forgery of direct delivery email (MTA=>MDA
without no intermediate hosts) is generally discovered by SPF, assuming the
SPF record of the sender is adequate.  This simply forces those who want to
perpetrate joe-jobs to pose as forwarders at throw-away domains with proper
SPF records.  They can use SRS or SUBMITTER and the message will be accepted
by most recipients despite a bogus originating domain (joe-job) claimed in
the return-path.  Neither SRS nor SUBMITTER can stop this for one simple
reason:  SPF is hop-by-hop authentication and cannot tell you anything about
any site prior to the present SMTP client.  You simply have to trust the
present SMTP client, if you choose to accept this limitation.  Even if the
forwarder is responsible, that is clearly not a wise thing to do.  The other
day, we saw an example of spam relayed through pobox.com, one of the best
and most responsible forwarders in the business, because of the setup chosen
by the account owner.  Trusting forwarders to act in the end recipient's
interest is not realistic because we don't pay their bills.

This gigantic loophole can be closed by using an adjunct protocol along with
SPF that does end-to-end validation of forwards.  SES is one such protocol.
The combination of SPF + SES gives you what SPF was designed for in the
first place:  confidence in the authenticity of the domain in the
return-path and immunity from joe-jobs.  If after any number of forwards,
you can contact the purported originating site through a very low-overhead
protocol and get them to vouch for the message, _now_ you know what domain
really sent it, regardless of who relayed it on its way to you.  The
reputation tools now being built can be applied to the originating domain,
which is what you really want to evaluate.

Keep in mind that every hop-by-hop authentication scheme has similar
weaknesses.  The only way to be sure of the originating domain for a message
in the presence of intermediate hosts to use an end-to-end protocol.  You
could use S/MIME, PGP or even DK, but those are all extremely high overhead
for the recipient and sender alike.  SES is extremely lightweight for both
sender and recipient and gives the same level of authentication as DK.
Since SES supports per-user keys, per-domain keys and per-MTA keys, you can
achieve as fine-grained authentication as you please.  The finer grained
keys are a minor burden on the sender side only, so senders can choose
whatever level of authentication they desire.

--

Seth Goodman


<Prev in Thread] Current Thread [Next in Thread>