Some of the later followups on this thread seem to diverge from Nate's original
point. Further amplification below.
At 03:30 PM 8/18/2004 -0700, Harry Katz wrote:
On Wednesday, August 18, 2004 2:34 PM, Nate Leon wrote:
I realize concern around this topic has been raised multiple
times (Dave Crocker, Doug Otis, Chris Haynes, etc...) but I
still can't help feel we are under-estimating the seriousness
of this issue. If I missed the posting where everybody
agreed on the solution (entirely possible) please point me to it. :)
I expect it will take years before all MUAs are updated (and widely
deployed) to display the PRA, which I do not think is an
acceptable timeframe to put a serious dent into phishing attacks.
For completeness, here is another example of the concern:
MAIL FROM:<> // don't care
RCPT TO:<valid-recipient(_at_)example(_dot_)com>
DATA
Subject: update your account info
Resent-From: JoePhisher(_at_)phishingScam(_dot_)com // valid domain
authenticated by MARID
...
From: account-services(_at_)yourbank(_dot_)com // Spoofed
domain,
displayed by the MUA
To: valid-recipient(_at_)example(_dot_)com // bummer for you
...
Are we really going to RFC with this issue left open?
If nothing else, I at least want to add my vote to more
thought being put into this topic.
To address the forged Sender/Resent problem I suggest we could add the
following logic:
If PRA != 2822.From and SPFCheck(PRA) != "Pass" then receiver MAY reject
a message after DATA.
In other words, if we validate an identity different from 2822.From,
then there's a higher bar for a message to be accepted. The higher bar
is that check of the SPF record must return PASS, else the receiver MAY
reject the message.
But I interpret Nate's "valid domain authenticated by MARID" comment above as
meaning that SPFCheck(PRA) == "Pass". So the message will be accepted, and
unless the MUA does display the PRA, the recipient will see just the From:
address (account-services(_at_)yourbank(_dot_)com in his example).
So it doesn't seem like Sender ID (as it is currently specified) will have done
much to improve things until MUAs catch up with it, which I expect to take some
time.
I would like to suggest that, if the PRA != 2822.From, 2822.From be rewritten
by the receiving MTA doing the MARID check, and the original From address be
copied into another header. In the majority of cases where there is a trusted
path between the MTA doing the checking and the recipient, this will at least
make it visible to a recipient using today's MUAs that the verification wasn't
based on the From address, but something else.
In Nate's example, I would suggest rewriting the From header as something like:
From: "[via <JoePhisher(_at_)phishingScam(_dot_)com>]"
<accountservices(_at_)yourbank(_dot_)com>
I haven't had a chance to think about whether further attacks are possible with
a rewritten From header, but without it I'm concerned that it will be quite a
long time before end users benefit from Sender ID, because those intent on
circumventing MARID will immediately adapt and use the Resent-From attack (or
the Sender: attack, or the Resent-Sender attack).
-Jim