[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[idn] Re: Unicode and Security
- To: Unicode List <unicode@unicode.org>
- Subject: [idn] Re: Unicode and Security
- From: Asmus Freytag <asmusf@ix.netcom.com>
- Date: Thu, 07 Feb 2002 13:12:04 -0800
- Cc: idn@ops.ietf.org,schneier@counterpane.com
- In-reply-to: <5.1.0.14.2.20020207100223.02d54710@i18n.com>
- References: <p04330110b88860b92563@[192.168.254.4]><p0433010ab8884ddfb787@[192.168.254.4]><F19ABF96-1B32-11D6-9AE2-003065F9CD7C@apple.com><p0433010ab8884ddfb787@[192.168.254.4]>
>>At 12:22 PM 2/7/2002 -0500, Elliotte Rusty Harold wrote:
>>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).
Substituting Greek for Latin works just as well with 8859-7 as with
Unicode. And (as I have argued separately) it will have to work with any
workable multilingual character set.
For the record it's worth noting that Unicode as a rule requires
additional
and strong justification before encoding characters that duplicate the
appearance of an existing character (but may have a different function).
The reason for that is not security, but the fact that such duplication
always carries with it the risk of unintentional misidentification and
therefore corrupt data. Such risk is mitigated for the characters from
different scripts (or different alphabets) since data entry methods
(keyboards) would normally allow access for only the proper character.
(If
I set my keyboard to Greek, I won't get the Latin "A" by accident).
Exceptions are found in some areas of punctuation. But good editing
software can make the distinction visible.
A security conscious browser could alert users to mixed Latin/Greek URLs
in
precisely the same way.
A./