Subject: [idn] Re: Unicode and Security

From: Elliotte Rusty Harold <[email-masked]>
Date: Thu, 7 Feb 2002 12:22:18 -0500

I've been thinking about security issues in Unicode, and I've come up
with one that's quite scary and worse than any I've heard before. It
uses only plaintext, no fonts involved, doesn't require buggy
software, and works over e-mail instead of the Web. All it requires
added to the existing infrastructure is internationalized domain
names. So in the hope that this becomes a self-defeating prophecy,
here's the scenario:

I as a reporter or industrial spy or detective working on a divorce
case, have learned the identities and internal e-mail addresses of
two people, call them Alice and Bob, at Microsoft (or just about any
other large company). I've somehow communicated with these people
personally, for instance on an e-mail list completely unrelated to
work but for which they use their work e-mail so I'm familiar with
their style and signature files. Or perhaps, I've communicated with
them on work related matters before. In any case, it's not hard to
get two people who know each other at a large company to send you
e-mail. Of course, they would presumably be careful not to give me
secret company information since they know they're talking to an
outsider.

For the sake of argument, let's call the company they work at
Microsoft, but this attack could hit most companies with a .com
address. Let's say I register microsoft.com, only the fifth letter
isn't a lower-case Latin o. It's actually a lower case Greek omicron.
I then forge a believable letter from [email-masked] to
[email-masked] saying "Can you please update me on your budget?"
Bob, noticing that the e-mail appears to come from Alice, whom he
knows and trusts, fires off a reply with his confidential
information. Only it doesn't go to Alice. It goes to me. I can then
reply to Bob, asking for clarification or more details. I can ask him
to attach the latest build of his software. I can carry on a
conversation in which Bob believes me to be Alice and spills his
guts. This is very, very bad.

E-mail forgery has been a problem for a long time, but it's always
been one-way. You couldn't trick somebody into sending you a reply
because doing so required using a different e-mail address than the
one they expected, thus revealing the message as forged. With a
Unicode enabled mailer, that's no longer true. If the fonts Bob (not
me, but Bob) chooses for his e-mail program do not make a clear
distinction between an o and an omicron, this works. There are lots
of other attacks. The Cyrillic and Greek alphabets provide lots of
options for replacing single letters in Latin domain names.

I'm not sure whether or not the internationalized domain names
working group has fully grokked this or not. Like Unicode, they seem
to be trying to pass the buck. In particular, they state
<http://www.ietf.org/internet-drafts/draft-ietf-idn-requirements-09.txt>
:

Specifying requirements for internationalized domain names does not
itself raise any new security issues. However, any change to the DNS
MAY affect the security of any protocol that relies on the DNS or on
DNS names. A thorough evaluation of those protocols for security
concerns will be needed when they are developed. In particular, IDNs
MUST be compatible with DNSSEC and, if multiple charsets or
representation forms are permitted, the implications of this
name-spoof MUST be throughly understood.

In other words, it's not our fault. Blame the client software. Sounds
distressingly like the Unicode Consortium's approach to these issues.
Interestingly, my attack works with a single character representation
(Unicode). It is not dependent on multiple charsets. I don't know if
the IDN working group has thought of this problem. I hope they have,
and consider it their responsibility to prevent. I also hope the
Unicode consortium and vendors of client software think about these
problems. But I don't think we can count on client software getting
this right. (Hell, Microsoft, can't even stop e-mail from running
scripts.)  The problem needs to be fixed closer to the source.
--

+-----------------------+------------------------+-------------------+
| Elliotte Rusty Harold | [email-masked] | Writer/Programmer |
+-----------------------+------------------------+-------------------+
|          The XML Bible, 2nd Edition (Hungry Minds, 2001)           |
|              http://www.ibiblio.org/xml/books/bible2/              |
|   http://www.amazon.com/exec/obidos/ISBN=0764547607/cafeaulaitA/   |
+----------------------------------+---------------------------------+
|  Read Cafe au Lait for Java News:  http://www.cafeaulait.org/      |
|  Read Cafe con Leche for XML News: http://www.ibiblio.org/xml/     |
+----------------------------------+---------------------------------+

---

From: John C Klensin <[email-masked]>
Date: Thu, 07 Feb 2002 16:25:13 -0500

Hi.

This is _really_ old news, old enough that some companies have
mail gateways set up to trap and reject outgoing mail that uses
spoofed variations on the company's name.  And, as has been
pointed out on the IDN WG's list, versions of the problem occur
even in ASCII.  I.e., whether you can tell MICROSOFT from
MICR0S0FT depends on your choice of fonts.

There is, incidentally, a much nastier attack capability
resulting from the tendencies of some mail clients to
automatically add names and addresses to address books and then
suppress the addresses entirely from the user display.

There are some interesting issues here.  The solution to them,
along with the rest of the large catalog of ways to spoof email,
is signed and encrypted mail.  Please don't waste the time of
this Working Group with it.

    thanks,
      john

--On Thursday, 07 February, 2002 12:22 -0500 Elliotte Rusty
Harold <[email-masked]> wrote:

> I've been thinking about security issues in Unicode, and I've
> come up with one that's quite scary and worse than any I've
> heard before. It uses only plaintext, no fonts involved,
> doesn't require buggy software, and works over e-mail instead
> of the Web. All it requires added to the existing
> infrastructure is internationalized domain names. So in the
> hope that this becomes a self-defeating prophecy, here's the
> scenario:
> 
> I as a reporter or industrial spy or detective working on a
> divorce case, have learned the identities and internal e-mail
> addresses of two people, call them Alice and Bob, at Microsoft
> (or just about any other large company). I've somehow
> communicated with these people personally, for instance on an
> e-mail list completely unrelated to work but for which they
> use their work e-mail so I'm familiar with their style and
> signature files. Or perhaps, I've communicated with them on
> work related matters before. In any case, it's not hard to get
> two people who know each other at a large company to send you
> e-mail. Of course, they would presumably be careful not to
> give me secret company information since they know they're
> talking to an outsider.
> 
> address. Let's say I register microsoft.com, only the fifth
> letter isn't a lower-case Latin o. It's actually a lower case
> Greek omicron. I then forge a believable letter from
> [email-masked] to [email-masked] saying "Can you
> please update me on your budget?" Bob, noticing that the
> e-mail appears to come from Alice, whom he knows and trusts,
> fires off a reply with his confidential information. Only it
> doesn't go to Alice. It goes to me. I can then reply to Bob,
> asking for clarification or more details. I can ask him to
> attach the latest build of his software. I can carry on a
> conversation in which Bob believes me to be Alice and spills
> his guts. This is very, very bad.
> 
> E-mail forgery has been a problem for a long time, but it's
> always been one-way. You couldn't trick somebody into sending
> you a reply because doing so required using a different e-mail
> address than the one they expected, thus revealing the message
> as forged. With a Unicode enabled mailer, that's no longer
> true. If the fonts Bob (not me, but Bob) chooses for his
> e-mail program do not make a clear distinction between an o
> and an omicron, this works. There are lots of other attacks.
> The Cyrillic and Greek alphabets provide lots of options for
> replacing single letters in Latin domain names.
> 
> working group has fully grokked this or not. Like Unicode,
> they seem to be trying to pass the buck. In particular, they
> state
> <http://www.ietf.org/internet-drafts/draft-ietf-idn-requiremen
> ts-09.txt> :
> 
> Specifying requirements for internationalized domain names
> does not itself raise any new security issues. However, any
> change to the DNS MAY affect the security of any protocol that
> relies on the DNS or on DNS names. A thorough evaluation of
> those protocols for security concerns will be needed when they
> are developed. In particular, IDNs MUST be compatible with
> DNSSEC and, if multiple charsets or representation forms are
> permitted, the implications of this name-spoof MUST be
> throughly understood.
> 
> In other words, it's not our fault. Blame the client software.
> Sounds distressingly like the Unicode Consortium's approach to
> these issues. Interestingly, my attack works with a single
> character representation (Unicode). It is not dependent on
> multiple charsets. I don't know if the IDN working group has
> thought of this problem. I hope they have, and consider it
> their responsibility to prevent. I also hope the Unicode
> consortium and vendors of client software think about these
> problems. But I don't think we can count on client software
> getting this right. (Hell, Microsoft, can't even stop e-mail
> from running scripts.)  The problem needs to be fixed closer
> to the source. --
> 

>| Elliotte Rusty Harold | [email-masked] |
>| Writer/Programmer |
>|          The XML Bible, 2nd Edition (Hungry Minds, 2001)
>|          | http://www.ibiblio.org/xml/books/bible2/
>|              |
>|   http://www.amazon.com/exec/obidos/ISBN=0764547607/cafeaulai
>|   tA/   |
>|  Read Cafe au Lait for Java News:  http://www.cafeaulait.org/
>|  | Read Cafe con Leche for XML News:
>|  http://www.ibiblio.org/xml/     |

---

From: "D. J. Bernstein" <[email-masked]>
Date: 8 Feb 2002 05:48:27 -0000

This discussion is being sent to two mailing lists, the IDN list and the
Unicode list. Some Unicode people don't know about IDNs, so I'll give a
brief introduction. At the end I'll address Klensin's comments.

IDNs are ``internationalized domain names.'' Imagine, for example, a
Greek pi in http://pi.cr.yp.to.

IETF created the IDN working group and the IDN mailing list---allegedly
open to the public, but the group chair sometimes censors objections---
to try to make IDNs work. The group chair has been pushing a specific
proposal, called IDNA; he has recently issued a Last Call for IDNA
despite objections to IDNA from many group participants.

There are three big issues surrounding IDNs:

   (1) How should characters be encoded?

       The obvious choice is UTF-8. Many existing programs already work
       with UTF-8 domain names. See http://pi.cr.yp.to for a discussion
       of what works and what has to be fixed.

       The IDNA proposal uses a new special-purpose 7-bit character
       encoding. The proponents claim that adding this new encoding to a
       huge number of programs will be less expensive than fixing the
       programs that have trouble with UTF-8.

   (2) Should two strings be treated separately as domain names if they
       are visually indistinguishable? For example, should someone be
       allowed to register aol.com, with o replaced by a Greek omicron?

       An answer of ``yes'' would introduce many new errors into common
       uses of domain names. Domain names are not hidden inside the
       computer; they are displayed for users, so that users can
       recognize known names. Visually indistinguishable domain names
       would make this function inherently unreliable.

       The IDNA proposal ignores this problem. The proponents observe
       that we're already faced with digit 0 and capital O, and digit 1
       and lowercase l; they then leap to the incredible conclusion that
       there's no harm in adding a bunch of new characters whose glyphs
       are similar or even identical.

       (On the other hand, IDNA prohibits all characters that look like
       hyphens, periods, etc.)

       The conservative approach, familiar in security contexts, is to
       have all new characters prohibited by default. The domain-name
       registries will then allow selected characters that have been
       carefully reviewed for problems.

   (3) Should two strings be treated identically as domain names if
       they are visually different but semantically similar? For
       example, should uppercase Pi.cr.yp.to, with a Greek Pi, be
       treated the same way as lowercase pi.cr.yp.to?

       The only existing semantic-similarity rule is that uppercase
       ASCII is treated the same way as lowercase ASCII. We're forced to
       continue treating uppercase ASCII the same way as lowercase ASCII
       for interoperability. But should there be more rules?

       There are several reasons to say no. First, new rules would have
       to be added to a huge number of programs that handle domain
       names. Second, new rules would make issue #2 substantially more
       difficult to solve: for example, if Greek lowercase alpha is
       treated the same way as uppercase Alpha, then alpha ol.com will
       conflict with aol.com, because Alpha OL.COM is visually identical
       to AOL.COM. Third, semantic similarity depends on the reader: for
       example, lowercase delta and uppercase Delta are semantically
       similar in Greece, but not in the United States. Fourth, semantic
       similarity is not transitive: for example, I see signs in France
       using capital E as a capitalization of e-accent-egu, and signs
       using capital E as a capitalization of e without an accent, but
       omitting the accent from e-accent-egu would be a misspelling.

       The IDNA proposal imposes a global set of uppercase-lowercase
       conversions. The proponents claim that, if we don't allow
       uppercase, we'll be flooded with complaints from users who tried
       typing domain names in uppercase. They don't respond when it is
       pointed out that users already handle case-sensitive lowercase
       URLs without trouble: blah.html works and BLAH.HTML doesn't.

       (It's funny how the IDNA proponents express such concern about
       the accuracy of users _typing_ domain names, but completely
       ignore the accuracy of users _reading_ domain names. See issue
       #2. Has it occurred to them that the domain names typed are, in
       almost all cases, copies of domain names previously read?)

       Meanwhile, the IDNA proposal ignores other questions of semantic
       similarity. There have already been a huge number of complaints
       about this from Chinese users. The IDNA proponents say that the
       complaints ``don't count.''

       The conservative---and cost-effective---approach is to start
       without any new rules, and have the registries prohibit
       characters that may be affected by new rules. Then new rules can
       be safely added later _if_ that turns out to be a good idea. For
       example, uppercase non-ASCII letters won't be treated the same
       way as lowercase, but they also won't be allowed in
       registrations,

Now, back to the current thread. The ``Unicode and Security'' message
explained one way that visually indistinguishable characters can be
exploited by attackers. This isn't a flaw in Unicode; it is a flaw in
careless protocol designs such as IDNA.

John C Klensin writes:
> spoofed variations on the company's name.

Here Klensin is admitting that IDNA will let attackers breach security.
These gateways are---unless modified in the last few months by an IDNA
proponent to use visual-similarity tables that the IDNA proponents say
don't exist---unaware of IDNA, and therefore unable to stop the attack
described in the ``Unicode and Security'' message.

> The solution to them, along with the rest of the large catalog of ways
> to spoof email, is signed and encrypted mail.

Speaking as a cryptographer: I find this ``cryptography solves all
security problems'' attitude to be astonishingly naive.

The problem here is not message forgery. The computer has accurately
identified the name of the sender. A cryptographic guarantee of
authenticity would do nothing to stop the attack.

The problem is in the design of the name system itself: how names are
assigned and used. The attacker was, as a matter of policy, allowed to
use a name visually indistinguishable from the target name. The name was
displayed on a computer screen. The display was read by the victim, and
used to authorize access.

One long-term solution is to drop all reliance on global name displays
in favor of local name displays (address books) defined entirely by the
user. In the short term, however, recipients will continue to use global
name displays to recognize known senders.

---D. J. Bernstein, Associate Professor, Department of Mathematics,
Statistics, and Computer Science, University of Illinois at Chicago

---

From: Mats Dufberg <[email-masked]>
Date: Sun, 10 Feb 2002 20:20:31 +0100 (CET)

> guts. This is very, very bad.
(...)
> name-spoof MUST be throughly understood.

DNSsec is compatible with ACE encoded IDN's. But the DNSsec keys and
signatures will be based on the ACE encoded domain, not the native IDN
domain.

Bob will not be helped by DNSsec in your scenario. Bob has been fooled to
use another mail domain, and that is beyond the scope of DNSsec.

Mats

----------------------------------------------------------------------
Mats Dufberg <[email-masked]>
----------------------------------------------------------------------