[idn] Re: Unicode and Security

[Barry Caplan <bcaplan@i18n.com>]

At 12:22 PM 2/7/2002 -0500, Elliotte Rusty Harold 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:
>
><snip>"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.


This is precisely the problem digital signing is meant to solve. Signing
means that Alice has encrypted the message with her private key before
sending to Bob. Bob then unencrypts the message using Alice's public
key.
If the message does not unencrypt, then Bob should not trust that the
message is from Alice. This algorithm works independent of transport
mechanism (email, etc.), or domains. Alice's key stays with Alice,not
with
the domain. Of course, how you exchange trusted keys in the first place
is
another matter, but I am sure this is all covered on a security FAQ
somewhere.


>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.

There are many many ways to get a response from someone via email, even
if
the address is not recognized or forged. Most involve social engineering
approaches more than anything else. My mailbox filled with spam will
attest
the that!


>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.


Unless all messages are signed (technically feasible) , then there is no
trust at all. When Outlook/Exchange supports, in fact requires, messages
to
be signed, then this problem will start to dwindle away, at least in the
email realm.

Of course if there is a method to judge the level of trust for properly
signed messages that arrive from folks you don't know (a human
failability), then knowing the origin of the message might not help much
either. My inbound spam can be verifiably signed, but it is still spam.

>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).


Your attack is only a social engineering attack, not a technical
weakness
inherent in any protocol, or character set (even though there may be
such
issues)

Barry