Subject: [ietf-dkim] Full name problem

From: Michael Deutschmann <[email-masked]>
Date: Sat, 26 Feb 2011 22:30:33 -0800 (PST)

There's one problem with DKIM as a phishing defense, which I have
mentioned in passing a few times here, but no one else seems to have
taken up discussion of.

An e-mail From: usually has two parts.  One is the email address itself.
The other part is the full name of the sender.  Usually the address is
enclosed in angle brackets while the remainer of the header is the full
name, although there is an alternative form where the full name is in
parentheses and the address is bare.

Full names are not used in routing and not registered anywhere.  Neither
DKIM nor anything else can validate them.  Nonetheless, in summaries of
incoming mail, MUAs tend to display *just* the full name.

Hence, I could send a phish as:

"From: PayPal <[email-masked]>"

and (so long as the content was good enough) fool an unsuspicious user
while passing ADSP with flying colors.

An already-suspicious user could see through it -- but such a user would
probably look at the other headers and notice anomalies without needing
the help of DKIM.  All ADSP would do is help declutter his mailbox of
the forgeries that don't use this trick.

By the way, this is why I consider the double-From: problem to be a
molehill.  If widely used, the double-From: would quickly appear in
SpamAssassin and the like -- one doesn't even need to do any
cryptographic work to detect and block it.  In contrast, detecting false
full names would require some sort of registry that does not exist at
present.

---- Michael Deutschmann <[email-masked]>
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: Dave CROCKER <[email-masked]>
Date: Sun, 27 Feb 2011 07:56:09 -0500

> parentheses and the address is bare.

You seem to begin with the belief that DKIM validates the email address in the 
From: field.  It doesn't.

In fact, DKIM is not a direct defense against phishing.  It validates an 
identifier in a message; the identifer is independent of the From: field and all 
other identifiers in the message.  The owner of the identifier might (or might 
not) have a positive reputation.  But DKIM says nothing about the validity of 
any other information in that message.

d/

ps. To the extent that a mechanism is claiming to validate the From: field, and 
to the extent that this is intended to extend to user-visible information, you 
are correct that the <display-name> string is of concern.  The recently deceased 
Goodmail validated the display-name.

-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: John Levine <[email-masked]>
Date: 27 Feb 2011 15:08:03 -0000

>"From: PayPal <[email-masked]>"

Um, you must be new here.  We've argued about this ad nauseam
over the years.

As Dave points out, DKIM does not "validate" anything other than that
the message you received is the same as the one the signer signed (for
a perhaps too complex version of "the same".)  Anyone can sign a
message which contains this:

 From: PayPal security <[email-masked]>

or even this:

 From: PayPal security <[email-masked]>

Despite a great deal of wishful thinking to the contrary, DKIM
signatures are only useful to the extent you recognize the signer and
have a good or bad opinion of the mail they sign.

This is one of the reasons I've argued that ADSP is not useful; that
it is trivial to circumvent if it becomes widely enough used to be
an issue for phishers.

R's,
John

---

From: Barry Leiba <[email-masked]>
Date: Sun, 27 Feb 2011 13:45:22 -0500

> Um, you must be new here.  We've argued about this ad nauseam

We have, but I think this is an unnecessarily brusque way to point that out.

In any case, let me cut this line of discussion off by saying that any
consideration of the "display name" portion of any address field is
out of scope.

Barry, as chair