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
On Aug 18, 2004, at 7:00 PM, Margaret Olson wrote:
On Aug 18, 2004, at 9:03 PM, Daryl Odnert wrote:
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.
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.
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.