On Sun, 2004-08-22 at 22:02, Jim Fenton wrote:
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>
Using this email as an example-
If there is an authenticated EHLO domain, then doing something like
moving the information out of the Received header to create something
like:
From: Jim Fenton <fenton(_at_)cisco(_dot_)com>
becomes:
From: "[Rcvd: above.proper.com*]" Jim Fenton <fenton(_at_)cisco(_dot_)com>
The '*' indicates successful completion of EHLO authentication. This
insertion would happen at the MTA at the edge of the administrative zone
receiving mail on behalf of the recipient, or by an MTA that (knows its
administrative zone and) authenticates all MTAs within this zone. If
there was already an insertion, it would be removed.
As a fall-back strategy, if the EHLO domain did not authenticate, the
most prominent header as determined by RFC2822 could be used instead.
Sender-ID, as currently defined, is too easily spoofed as a primary ID
display offered users. The name of the header being extracted should be
indicated within this notation. I suspect there will be games played
with an algorithmic selection of headers, where revealing the header
selection could provide a heads up. Not just "via" but a short-hand of
the headers.
-Doug