[idn] Re: Unicode and Security

[Elliotte Rusty Harold <elharo@metalab.unc.edu>]

At 9:52 PM +0100 2/9/02, Lars Marius Garshol wrote:


>It seems to me that this problem really needs some other fix than the
>merging of all similar-looking characters in all character sets. I
>just can't see that working.
>

That's your suggestion, not mine. I have never proposed merging all 
the similar looking characters. If I misspoke or something I wrote 
was misinterpreted as indicating that, I apologize. But that is not 
now nor ever was my position.

However, I do continue to maintain that character confusion is a real 
security risk that will have real impact on users, and that needs to 
be considered in any system that uses Unicode. In some domains the 
problem might be severe enough to eliminate Unicode from 
consideration in favor of less extensive character sets like Latin-1. 
That would be a shame, but until the Unicode consortium addresses at 
a root level the real security implications of their work, security 
conscious developers will look elsewhere. (I notice the Unicode 3.0 
book does not even have the word "security" in its index.) Many more 
developers who are at best tangentially conscious of security issues 
will go ahead and develop insecure systems because they don't realize 
the security implications of adopting Unicode.

There might be other solutions. I have proposed forbidding mixed 
block domain names; e.g. allowing Cyrillic names and Latin names but 
not mixed Cyrillic-Latin names. To me, that seems a reasonable 
trade-off. Vastly improved spoof-resistance (though still not 
perfect) while still allowing the registration of most desired 
localized names.

Another possibility is a super-normalization that does combine 
similar looking Unicode characters; e.g. in the domain name system we 
might decide that microsoft.com with Latin o's or Cyrillic o's or 
Greek o's is to resolve to the same address. No separate registration 
would be necessary or possible. This would require detailed analysis 
of the tens of thousands of Unicode characters allowed in domain 
names by fluent speakers of various languages; not easy, not cheap, 
but perhaps necessary. Besides, the security improvements, this 
proposal would also improve the system's usability. Aren't sure 
whether that URL on the bus used an o or an omicron? Doesn't matter, 
type either one.

>Similarly, the "security problems" caused by using Unicode encoding
>tricks to hide or mangle text in, say, contracts, is no different from
>using HTML or CSS (or whatever) tricks to achieve the same effect, and
>yet nobody is talking about security problems with HTML or CSS. See
>[1] for one way of dealing with it that is now being worked on.
>

Actually, people have been talking about the security problems with 
HTML for years. Search engines have gone to some effort to eliminate 
spamdexers that use these techniques. The log in HTML's eye does not, 
however, negate the existence of the log in Unicode's eye.

>So while I accept that there is a problem it does not seem to me that
>Unicode is the problem. To me the problem seems to be the complexity
>of the relationship between the bytes sent to the user and what the
>user actually sees and reacts to. That complexity is not going to
>disappear, and aspects of the same "problem" exist with just about any
>information representation, so clearly the solution must be something
>other than changing all of these syntaxes/formats/encodings.
>
>In the specific case you cite, for example, a better solution might be
>for the user's email client to keep track of all the user's contacts
>and for it to indicate in some clearly visible way whether the current
>email comes from one of them or not. Whether it uses string matching
>of email addresses or digital signatures to do that doesn't really
>matter; it solves the problem in your example either way.
>

If the internationalized domain name system comes into being without 
any resistance to spoofing, I will certainly recommend that people 
upgrade their client software to prevent this, just as I recommend 
today that people avoid Outlook Express, Microsoft Office, and other 
products that provide fertile soil for worms. I expect such efforts 
to be about equally effective; i.e. some wiser users will protect 
themselves. Many other users will be protected by accident. And many 
more users will not be protected at all.
-- 

+-----------------------+------------------------+-------------------+
| Elliotte Rusty Harold | elharo@metalab.unc.edu | 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/     |
+----------------------------------+---------------------------------+