[ietf-dkim] dkim-threat-02 3.2. Use of Specific Identities
2006-01-06 21:02:01
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(_dot_)com is from admin(_at_)example(_dot_)com(_dot_) 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(_dot_)co,
and one living in England may not question admin(_at_)example(_dot_)co(_dot_)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
_______________________________________________
ietf-dkim mailing list
http://dkim.org
<Prev in Thread] |
Current Thread |
[Next in Thread>
|
- [ietf-dkim] dkim-threat-02 3.2. Use of Specific Identities,
Douglas Otis <=
|
|
|