Subject: Re: [ietf-dkim] Full name problem

From: Michael Deutschmann <[email-masked]>
Date: Tue, 1 Mar 2011 15:11:50 -0800 (PST)

On 27 Feb 2011, John Levine wrote:
> Um, you must be new here.  We've argued about this ad nauseam
> over the years.

I've been subscribed since Janurary 2008.  Although my eyes may have
glazed over during some of the longer threads....

There are two uses for a protocol similar to DKIM/ADSP.

#1: it can be used as one of many general mailbox decluttering weapons,
reducing the amount of "bad mail" of various sorts that the end recipient
has to sort through with his own eyes.

#2: it can be used to stop phishes from being successful, by preventing
gullible users from even seeing them.

The immediate responses I'm getting in this thread suggest the intended
mission of DKIM is #1.  Which is what I thought in the very first place,
as the Full Name Problem makes mission #2 rather problematic.

And yet, two things on this list seem to indicate that there are people
here who think #2 is the mission:

First, there's the whole double-From: fuss.  The demand for coercive
language on this minor point only makes sense on the assumption that the
recipient admin is not eager to block suspect mail; that he is only
implementing ADSP for some sort of Good Netizenship ticklist.

Second, one of the responses I've gotten to my "except-mlist" proposal
is that the domains for which it would be superior to TPA (consumer
ISPs, basically) are not phish targets.  That is true, but it is only a
counterargument under mission #2.  Under mission #1, it is just as
valuable to block [email-masked] forgeries as [email-masked] forgeries.

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

---

From: "MH Michael Hammer (5304)" <[email-masked]>
Date: Tue, 1 Mar 2011 18:47:20 -0500

> -----Original Message-----
> From: [email-masked] [mailto:ietf-dkim-
> [email-masked]] On Behalf Of Michael Deutschmann
> Sent: Tuesday, March 01, 2011 6:12 PM
> To: [email-masked]
> Subject: Re: [ietf-dkim] Full name problem
> 

DKIM signing in and of itself is neither #1 nor is it #2. In the
broadest sense it is simply a party signing a message and taking
"responsibility" for it. When we get into a discussion of 1st party vs
3rd party signatures it is possible to infer specific value in terms of
phishing with regard to the From email address (which is where ADSP
comes in).

> implementing ADSP for some sort of Good Netizenship ticklist.

The fuss centers on specific technical attacks that have been
identified. While the problem is broader than DKIM, they create problems
that potentially reduce (subvert?) the value of the DKIM signing
proposition depending on what a validator does and how the message is
subsequently handled.

> ---- Michael Deutschmann <[email-masked]>

The display name is problematic as Mr. Crocker has pointed out. One
solution to this which I have suggested in the past is to not display
the display name in the MUA if the email fails to authenticate. This
would require reaching some tipping point in authenticated mail
implementation where receivers/MUA providers perceive a value
proposition that provides benefit greater than the perceived detriment
for legitimate mail which is not authenticated.

Such an approach also raises the hackles of some email purists.

Mike

---

From: "John R. Levine" <[email-masked]>
Date: 1 Mar 2011 20:35:08 -0500

> gullible users from even seeing them.

I fear the wishful thinking problem has arisen here.  DKIM simply allows 
someone in the mail path to attach a domain identity to a message.  It 
doesn't reduce "bad mail", or does it stop phishes.  As I noted before 
it's only useful insofar as you can use the signing domain identity to 
sort the messages.

In the near term, its most likely utility is to whitelist mail from 
signers you trust, either ones you know directly, or ones published by a 
credible third party via VBR.

> mission of DKIM is #1.

Nope.

Regards,
John Levine, [email-masked], Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. http://jl.ly
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: Michael Deutschmann <[email-masked]>
Date: Wed, 2 Mar 2011 00:19:36 -0800 (PST)

On Tue, 1 Mar 2011, MH Michael Hammer wrote:
> the display name in the MUA if the email fails to authenticate.

That won't help.  The attack mail will authenticate successfully -- the
attack hurts because the identity the *computer* thinks it was expected to
verify is not the identity the *human* thinks has been verified.

Both the double-From: and the Full Name attack rely on that principle,
but the double-From: is less of a threat.  Since double-From: is based on
a protocol violation with no history of accidental use, it can be blocked
with no false positives.  (Also, there's a half a chance the MUA will
display the From: the attacker intended only for the validator, to the
human.)

To fix this in the MUA, I'd have it strip the Full Name from *all*
messages, then re-insert the Full Name as listed in the user's address
book if there is any match against the real address.

---

From: "MH Michael Hammer (5304)" <[email-masked]>
Date: Wed, 2 Mar 2011 03:55:33 -0500

Comments inline.

> Sent: Wednesday, March 02, 2011 3:20 AM
> attack hurts because the identity the *computer* thinks it was
expected
> to

It is admittedly an imperfect solution at best for the case you
describe, but it provides a linkage to the authenticated email address
if the attacker is DKIM signing. What it does accomplish is to drive
attackers to self authenticate. While some phishing emails will get
through initially, the signing entity should end up with a poor/negative
reputation. Attackers might use "throw away" signing entities but this
might provide actionable (reputation) indicators as well.

This is of course somewhat speculative as we have yet to see (publicly
disclosed if they exist) significant reputation systems built
specifically around DKIM signing.

> human.

This relies on the user having the entries in the address book. As many
marketers would tell you, easier said than done when it comes to
corporate/organizational mail. I can't speak to mail from individuals.

---

From: Michael Deutschmann <[email-masked]>
Date: Wed, 2 Mar 2011 02:18:32 -0800 (PST)

> corporate/organizational mail. I can't speak to mail from individuals.

The mail wouldn't be blocked -- it would just be presented to the user
with only the raw computer e-mail address.  This might annoy a company's
branding ambitions, but it wouldn't be fatal.

(This means that the phish-preventing effect still counts on the user
realizing that a mail bearing, say, a @hotmail.com domain is unlikely to
speak for PayPal.  All it does is make him more likely to notice by
removing the distraction of an exactly-as-expected full name.)

---

From: Barry Leiba <[email-masked]>
Date: Wed, 2 Mar 2011 10:14:17 -0500

I repeat:
Any consideration of the display-name field and any discussion of what
user interfaces might oughta do with them is out of scope for this
working group.

The chairs have no direct objection to having side discussions of
those topics on this list as long as they don't distract us from
dealing with the documents we're working on (currently 4871bis, and
soon the mailing-lists document), but we suggest that there are other
DKIM discussion lists on mipassoc.org that'd be more appropriate.

Please put your energy into making sure that 4871bis is ready to go;
we will be discussing open issues on that document at the Prague
meeting, and we intend to send it to the IESG in April.

Barry, as chair

---

From: "McDowell, Brett" <[email-masked]>
Date: Wed, 2 Mar 2011 07:55:33 -0700

On Mar 2, 2011, at 3:19 AM, Michael Deutschmann wrote:

> That won't help. 

I'm not sure who can say whether or not this will help until sufficient usability testings has been done.

> book if there is any match against the real address.

That's another idea that could/should be tested.

The point being made on this thread is one I share, i.e. the MUA has a role to play as an active client in email authentication scenarios.  That's not yet a consensus, but the concept is gaining momentum.

It comes down to usability testing, useful metrics, and peer-reviewed data analysis.  Then we should really know what we should be doing with the MUA, if anything.

All that said, I don't believe MUA behavior is in scope for this IETF WG.

-- Brett