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

From: Douglas Otis <[email-masked]>
Date: Fri, 6 Jan 2006 19:47:27 -0800

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 [email-masked] is from [email-masked].  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 [email-masked],  
and one living in England may not question [email-masked] 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

---

From: Jim Fenton <[email-masked]>
Date: Thu, 19 Jan 2006 17:21:35 -0800

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:
> 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. : )
>
>
> 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.
> 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.
> 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
A good point.  I'll add something about this in 4.2.1 as well.
> 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 [email-masked] is from [email-masked].  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 [email-masked], and one
> living in England may not question [email-masked] 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.
>
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
> 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.
>
> program should dramatically reduce the number of successful deliveries
> of these types of spoofs.
>
> -Doug
>

---

From: Douglas Otis <[email-masked]>
Date: Thu, 19 Jan 2006 18:15:17 -0800

On Jan 19, 2006, at 5:21 PM, Jim Fenton wrote:

The section 3.2. Use of Specific Identities constrains itself to what  
the recipient sees in every case.  Concerns related to fallibility of  
humans being able to remember and recognize these identifiers would  
be an attack on the identity or SSP, but _not_ DKIM.  These issues  
are important from the perspective of usurping the use of an identity  
which is the topic of this section.  When relying upon humans to  
preform a validation of the identifier, it would appropriate to  
discuss the frailness of this validation within this section.  At  
least reference these other sections.

> registrations rather than defensive acquisition of similar domain  
> names as I think the monitoring will be needed by high-value  
> domains regardless.

By the time a look-alike domain is noticed, much of the damage may  
have already been done.  Many of these attacks could be measured in  
hours.  There are many registrars involved and thousands of possible  
names.  How timely will the potentially conflicting domain-names be  
reported, and how quickly can this domain be removed?  Don't overlook  
the record TTLs.  To be effective in a timely manner, services need  
to be stopped by the network provider.  The timeliness would then  
assume providers can be contacted immediately, and that they  
understand and believe the request to be legitimate.

Keep in mind, a recognition scheme used in conjunction with DKIM  
never suffers from this susceptibility.  There would be no emergency  
calls to Korea at 3 AM local-time, or keeping tabs on or the  
registering of thousands of possible names.   In the threat draft, it  
would be good to clarify what is being attacked.  DKIM does not have  
this problem, SSP does.

-Doug