[ietf-dkim] dkim-threat-02 3.2. Use of Specific Identities

Douglas Otis dotis at mail-abuse.org
Fri Jan 6 19:47:27 PST 2006


Here is some suggested text for this section.  Rather than suggesting  
that DKIM offers little, it strives to make the point that a reaction  
by bad actors to dkim must be anticipated.  Frankly, I don't see how  
an authorization scheme helps in this matter.  The immediate benefit  
is found in filtering, the eventual benefit would be anti-spoofing  
for even individual addresses, but without administrative efforts.   
People already have many out of band clues. : )


3.2.  Use of Specific Identities

A second major class of bad acts involves the assertion of specific  
identities in email.

Most recipients are likely using an email application that displays  
the the display-name (also known as the “pretty-name”) rather than  
the actual email address.  Even when the email address is visible to  
the recipient, visual identification confronts an expansive character- 
repertoire found in the modern operating system.  Within an email,  
these  characters, ideograms and glyphs are selected by the sender  
using mechanisms enabled by RFC2047 or RFC3490, RFC3491, and RFC3492.

The diversity of possible characters diminishes reliance upon even  
recognizing syntax, let alone individual characters, ideograms, and  
glyphs.  Some applications have also chosen to not implement the  
translation of the ACE labels containing punycode for display  
purposes, but show the raw ACE labels instead.  Displaying
xn--cjsp26b3obxw7f.com will not greatly improve upon the domain  
recognition for the Chinese speaking user, or even an English  
speaking user for that matter.  The alternative of displaying the  
ideograms and extended characters adds new look-alike domain names  
that can also be exploited.

It is common for email-addresses to also have an append a sub-domain  
which is often used as an administrative mechanism by large  
organizations.  Visual identification of an accountable domain  
assumes the recipient understands the hierarchy of assignments within  
a domain name.  As it turns out, many do not understand the  
difference between
“online-bigbank.com” and “online.bigbank.com”.  To make this problem  
even more confusing, institutions subjected to spoofing also make  
similar changes to their domain name, sometimes just to differentiate  
their various services.

Simple ASCII text is also often used to mislead the visual  
identification by the recipient.  For example, if the bad actor is  
able to control the domain "examp1e.com" (note the "one" between the  
p and e), they might be able to convince some recipients that a  
message from admin at examp1e.com is from admin at example.com.  There are  
also hundreds of top level domains where international enterprises  
could be expected to also employ the country codes and sub-categories  
of the various locales.  A recipient may not notice admin at example.co,  
and one living in England may not question admin at example.co.uk as  
belonging to a different entity or remember that it should have been  
“.com”.

Visual identification also must contend with the subconscious  
activity of the mind making transparent corrections when anticipating  
a particular label.  The mind often ignores three sequential ells  
when looking for two, or various transpositions of letters.  The bad  
actors know how even a cautious person is easily fooled and all the  
visual tricks.  Often in more detail than the legitimate domain owner.

Reliance upon visual identification produces a sizable expense when  
the legitimate domain owner attempts to protect their customers.  To  
offer protection, the domain owner must acquire look-alike domains.   
Often, the acquisition of these domains involves an expensive  
litigation process, in addition to the annual fees demanded by the  
registrars. An extensive effort to protect their customers from being  
mislead may involve the acquisition of thousands of domain names.

DKIM can provide a solution for this problem. The DKIM signature  
offers a means to recognize the source of a prior correspondent.   
With a specialized MUA, initial message source identifiers could be  
registered by the recipient when a relationship is first  
established.  Perhaps bigbank.com returns a pass-phrase that the  
recipient selected when signing up for a service.  This added  
information provides an “out-of-band” means to confirm the source of  
the message.  Once the message source is registered by the recipient,  
all subsequent messages should be identifiable by the email  
application and thus highlighted.

Highlighting those messages that have been authorized could easily  
lower the defenses of the recipient into not being as careful when   
examining the domain name.  Bad actors are equally capable of  
registering domains and providing the requisite authorization.   
Highlighting the recognition of a prior source would be a far safer  
alternative and would not rely upon the recipient's visual acuity.

Erecting barriers only invites alternative methods with a vengeance.   
Anticipating the next ploy moves DKIM ahead of the bad actors. In  
addition, this approach requires substantially less administration  
than would an authorization scheme, and depends totally upon what is  
already contained within the message.  No additional lookups by the  
receiving MTA are required, as apposed to walking the label tree  
looking for authorization records.  Only a fractional percentage of  
the domains would find restrictive authorizations appropriate, and  
hence few would be cached ensuring this would be an expensive  
operation.  Not adding to the burden of the receiver is a highly  
critical consideration for any abatement effort.

The MUA does not need to change for DKIM to increase the protection  
afforded the recipient.  Spoofing that attempts to mimic message from  
financial institutions often include deceptive links expecting the  
recipient to click for access to a web page.  The stability of the  
DKIM identity affords far greater sensitivity for email filters while  
ensuring a much lower false positive rate.  These filtering  
applications are commonly well aware which domains are being  
attacked.  The DKIM verification of the identity for the filtering  
program should dramatically reduce the number of successful  
deliveries of these types of spoofs.

-Doug





More information about the ietf-dkim mailing list