Subject: RE: Forged Sender (Resent-From) attacks

From: "Daryl Odnert" <[email-masked]>
Date: Wed, 18 Aug 2004 18:03:51 -0700

Nate Leon wrote:
> 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.

My personal opinion is that solutions to the phishing problem
absolutely require changes to MUAs.  It is simply not enough
to tell all email users to start trusting that email is "more
secure" after some date when Sender ID goes to RFC.

There needs to be some way that recipients can easily distinguish
mail that has been authenticated versus mail that has not.  Period.

Until that happens and people understand the difference, the phishing
problem is unlikely to go away.  The closest analogy I can think of
is that once upon a time, there was no SSL on the Web.  But HTTP over
SSL wasn't enough to secure the Web.  The lock icon in the browsers
were needed too so users could tell the difference between what is
trustworthy and what is not.

Daryl Odnert
Tumbleweed Communications
Redwood City, California

---

From: Margaret Olson <[email-masked]>
Date: Wed, 18 Aug 2004 22:00:07 -0400

On Aug 18, 2004, at 9:03 PM, Daryl Odnert wrote:

>  But HTTP over

And the lock on the browser came after the SSL standard.
SenderID is the first step, and a necessary step, not an instant cure 
for all that ails email.

Margaret.

---

From: Mark Baugher <[email-masked]>
Date: Thu, 19 Aug 2004 09:18:46 -0700

There are a number of problems with present-day secure web 
transactions, which typically use SSL.  For starters, the server does 
the authentication by querying the user for a password but not vice 
versa.  Many servers ask for a secret question and use the answer to 
expedite lost password recovery but don't allow the user to even ask 
what the secret question is.  And web servers typically get a lot of 
authenticating information from the user, who has very little to go on 
beyond a natural-language-looking domain name that is vulnerable to 
social-engineering attacks and simple mistakes such as typos.  All of 
this has been considered in RFC 2693, Risks, and other places.

My point here is that it is not reasonable to expect that an MTA 
authorization record is going to do much to alleviate phishing beyond 
removing one delivery option, i.e. an email message with a forged from 
address.  More extensive cryptographic mechanisms might help, if you 
believe these mechanisms are suitable for most consumers.  But I don't 
see how MARID can do more than mitigate _one type_ of phishing attack.

Mark