ietf-dkim
[Top] [All Lists]

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

2006-01-19 18:29:50
Doug,

I'm getting back to this as I'm in the editing process (and close to the
end, I think/hope!) for the next iteration of the threats document. 
Comments inline.

Douglas Otis wrote:
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.
Display-name abuse is covered in section 4.1.15.  I have included it as
a threat against DKIM (section 4.1.x) rather than as a current threat,
because it's currently trivial to falsify the entire email address,
there isn't any reason to exploit the display-name by itself. 
Regardless of where it falls, I think I have captured your point here.

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.
This is similar to 4.2.1, "Look-Alike Domain Names".  I'll add something
there to talk about the difficulty in recognizing domain names that are
poorly rendered by the MUA.

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.
A good point.  I'll add something about this in 4.2.1 as well.

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.
Much of this is covered on 4.2.1.  I suggested monitoring domain
registrations rather than defensive acquisition of similar domain names
as I think the monitoring will be needed by high-value domains regardless.

I consider much of the discussion below to digress from the purpose of
the threat document. I'd like to stick to describing the threat
characteristics of DKIM as currently envisioned rather than invent new
solutions in the threat document.

-Jim


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>