Onderwerp: thoughts and a possible solution on homograph attacks

Hi security community,

this is my first publication I post on Bugtraq, so please be patient with me.

Since the recent problems with IDN, I wanted to clear up my thoughts on
homograph attacks, so I sorted everything in an article which also contains
what I believe to be an easy and general solution.

You can find it here:
http://www.amalthea.de/publications/homograph.pdf

Unfortunately, my free time is currently limited, so I may not be able to
participate too much in any discussions on the subject. My appologies for
that. But I will definitely read any feedback I receive.

Michael Roitzsch

Michael,

I don't think this solution is appropriate at all. (For those that
didn't read the PDF, the idea is to have the user _type in_ the domain
name of a url they clicked on).

Clearly, this won't work at all from a users point of view. It would
be far too annoying. Your saving scenario is also not very
appropriate, because consider if a malicious user on that persons
computer saves 'bank1.com' to map to 'hackerbank1.com'. The problems
become obvious.

As for a solution to the problem, perhaps browsers can just notify
the user when a domain they clicked contains unicode characters, and
display the URL in some special fashion. (I can't think of anything
that would be appropriate, however

-- Michael (Silk)


On Mon, 7 Mar 2005 18:25:31 +0100, Michael Roitzsch <amalthea@freenet.de> wrote:
> Hi security community,
>
> this is my first publication I post on Bugtraq, so please be patient with me.
>
> Since the recent problems with IDN, I wanted to clear up my thoughts on
> homograph attacks, so I sorted everything in an article which also contains
> what I believe to be an easy and general solution.
>
> You can find it here:
> http://www.amalthea.de/publications/homograph.pdf
>
> Unfortunately, my free time is currently limited, so I may not be able to
> participate too much in any discussions on the subject. My appologies for
> that. But I will definitely read any feedback I receive.
>
> Michael Roitzsch
>


--
Please adjust the reply-to address.

On Mar 7, 2005, at 11:25 AM, Michael Roitzsch wrote:

> Hi security community,
>
> this is my first publication I post on Bugtraq, so please be patient=20=

> with me.
>
> Since the recent problems with IDN, I wanted to clear up my thoughts =
on
> homograph attacks, so I sorted everything in an article which also=20
> contains
> what I believe to be an easy and general solution.
>
> You can find it here:
> http://www.amalthea.de/publications/homograph.pdf
>
> Unfortunately, my free time is currently limited, so I may not be able=20=

> to
> participate too much in any discussions on the subject. My appologies=20=

> for
> that. But I will definitely read any feedback I receive.
>
> Michael Roitzsch
>

That's an interesting idea, but it sounds kinda complicated and=20
burdensome on the user. It would be hard sell to make that the default=20=

behavior in any browser if users aren't accustomed to dealing with it.=20=

It's incredibly difficult to convince a user that adding more work to=20
them is somehow an improvement on things.


What would (to me) make more sense is if the browser made it more clear=20=

that a homograph was being used.

In the address bar, any character that's not from the user's language=20
character set(or family of languages possibly) would appear as a=20
different color. Maybe make the foreign characters red, or the=20
background color around each foreign character blue or something.

It still would require a bit of user education, but maybe the first=20
time it happened the browser can pop up with "The address of the site=20
you are going to contains characters from another language. If you=20
clicked on a link to a site you expected to be in [User's default=20
language], you might be going to a fraudulent site. The questionable=20
characters are highlighted in blue in the address bar above. [x] Do not=20=

show this again for Cyrillic language letters"

Users using an english browser could view URLs with known "acceptable"=20=

characters in other languages like =E9, =F8 and other obvious =
differences=20
with no problem, but if a user clicks on a link with a known homograph=20=

in another character set (like #0430 - CYRILLIC SMALL LETTER A) they=20
get the scary warning of doom.

Novice users may not understand the problem, but the fact that the=20
browser popped up with something would be a good indication that=20
something is wrong. Expert users or those who frequently deal with=20
sites in other languages could whitelist character sets that they use.

Even when a user does whitelist a character set, they would still=20
hopefully notice the obvious color change in the address bar.


-- Kevin

On Mon, Mar 07, 2005 at 06:25:31PM +0100, Michael Roitzsch wrote:
> Hi security community,
>
> this is my first publication I post on Bugtraq, so please be patient with me.
>
> Since the recent problems with IDN, I wanted to clear up my thoughts on
> homograph attacks, so I sorted everything in an article which also contains
> what I believe to be an easy and general solution.

Guts are :-

|| I propose to present the user with a dialog showing the text to be
|| validated and an input field, into which the user has to type in the
|| given text again. The user is told, if both texts match precisely and
|| what this means: If the typed text's internal representation matches
|| the given text bit-by-bit, trust can be established. If it does not
|| match, the user is told to re-check for typing errors and not to
|| establish trust.


Problems with this approach:-

1. The user will see this as an irritation and won't percieve it as
helping them keep their computer secure. Hence they will want to
turn the feature off. People select usability over security unless
they clearly understand the security problem and the usability
difference is manageable.

2. The earlier description says that the quoted actions should occur
"Whenever the user has to validate textual information to establish
trust," but it is my belief that that even includes the case where
the user starts a blank browser and then pastes a URL into the
address box.

3. "matches the given text bit-by-bit" can give spurious negative
results in many circumstances. This particularly applies to those
languages making use of Unicode "combining marks". Combining
characters are additional marks following a main character that are
essentially "decorations" to it. Usually the order of combining
characters is significant, and the user would be able to see the
difference between the orderings (and therefore will know what
order to type their characters to get the same effect they see).
However, there are also other types of combining characters that
have the same rendering no matter what order they're presented in.
This is very similar though to the original problem and it is not
clear to me that domain names containing such combining characters
should be allowed (otherwise there will be two alternative Unicode
code point sequences that appear the same but are actually
different domain names, as I understand things).

I suspect that where a domain name contains a sequence of combining
characters of differing combining classes, the right thing to do is
to allow as a registered domain name only the renderings in which
the marks are encoded in the "canonical order". See section 3.11
of the Unicode Standard, version 4.0. Apologies if I have
misunderstood this area of Unicode, it's a bit complicated and I
don't have a history of immersion in Unicode. The summary of my
third point then is possibly that worrying about the possible
differences of ordering of combining marks is probably the
responsibility of whoever oversees the registration of the IDN, and
probably isn't something we can be expected to solve in every piece
of client software.

The length of this email is out of proportion to its usefulness. Sorry.

James.

Michael Roitzsch wrote:
> You can find it here:
> http://www.amalthea.de/publications/homograph.pdf

Quote from the abovementioned paper:
"I propose to present the user with a dialog showing the text to be validated and
an input field, into which the user has to type in the given text again. The user
is told, if both texts match precisely and what this means: If the typed text's
internal representation matches the given text bit-by-bit, trust can be established.
If it does not match, the user is told to re-check for typing errors and not to
establish trust."

You completely seem to forget to think about user *acceptance*. Noone
will accept such a "solution". If I think of me alone I would hate to
enter the domain name once I click on a link. And obviously this would
have to be done for *every* link the user clicks, or how would you
technically distinguish between a trustable and non-trustable URL. Heck,
that's actually the root of the problem ...

Tom

On Mon, 7 Mar 2005, Michael Roitzsch wrote:

> Hi security community,
>
> this is my first publication I post on Bugtraq, so please be patient with me.
>
> Since the recent problems with IDN, I wanted to clear up my thoughts on
> homograph attacks, so I sorted everything in an article which also contains
> what I believe to be an easy and general solution.
>
> You can find it here:
> http://www.amalthea.de/publications/homograph.pdf
>
> Unfortunately, my free time is currently limited, so I may not be able to
> participate too much in any discussions on the subject. My appologies for
> that. But I will definitely read any feedback I receive.

You are far too fast to dismiss the usability criticism. People _WON'T_
participate in a system requiring them to retype the domain name to
establish an SSL connection. Additionally, it would fail in the case
where a user's locale was (for example) Greek while the site they were
connecting to was American. They would type what they perceived to be the
domain - and it wouldn't work. A "reverse homograph" failure.

It is a technically nice but completely unusable solution.

--
Jerry

"All right, where is the answer? The battle of wits has begun.
It ends when you click and we both serve pages - and find out who is right,
and who is slashdotted." - David Brandt

Michael,
A few comments. First, in response to:

>I propose to present the user with a dialog showing the text to be
>validated and an input field, into which the user has to type in the
given >text again. The user is told, if both texts match precisely and
what this >means: If the typed text's internal representation matches
the given text >bit-by-bit, trust can be established. If it does not
match, the user is >told to re-check for typing errors and not to
establish trust.

It's very difficult to get people to agree to security at the expense of
usability. The average user thinks of security as a commodity to be
bolted on. Those in the field know that this is never the case, but
they'll have a hard time convincing my mom to re-type what she sees in a
box each time she clicks on a hyperlink. There *must* be a better way.

A few such ways come to mind:

It's rather trivial to determine programatically that www.paypal.com is
different from www.paypa1.com, but look similar. One might argue to rest
the burden with DNS registries (why would anyone legitimately want
paypa1.com?), but that's not likely to fly. Could it rest within the
browser? ("Hey buddy, you're going to paypa1.com--did you mean Pay Pal?"
or "Enable Unicode in URLs"). Perhaps with an addon ("Hey buddy, you're
going to a restricted domain-- are you sure?"). Finally, it could rest
with the operating system (via a variety of mechanisms).=20

The danger of 'O' vs '0' isn't trivial, but it is much less dangerous
than ASCII 'a' vs Unicode 'a', where the two don't map to the same
Unicode value. At the most basic level, there's the trust that when I
see a picture of 'a', then that means, the first letter of the alphabet,
etc. It shouldn't mean, a modified Greek font representation of a
chinese glyph, or whatever. Perhaps this should rest with the font
designers. Perhaps the default fonts that come preloaded (Arial, Times,
Verdana, etc) shouldn't have multiple characters to map to the same
glyph? After all, I'm not going to paypal.com, I'm going to p<some
unicode character>ypal.com. Why should that look just like paypal.com to
me?

<plug>
I've released a "fix" for the IDN vulnerability
(www.scovettalabs.com/advisory/SCL-2005.002.txt) that basically prevents
you from going to *any* domain that has a non-[\-A-Z0-9] character in
it. For me, it's fine, since I'll likely never need to go to an IDN
domain.
</plug>


Michael Scovetta
Computer Associates
Senior Application Developer

-----Original Message-----
From: Michael Roitzsch [mailto:amalthea@freenet.de]=20
Sent: Monday, March 07, 2005 12:26 PM
To: bugtraq@securityfocus.com
Subject: thoughts and a possible solution on homograph attacks

Hi security community,

this is my first publication I post on Bugtraq, so please be patient
with me.

Since the recent problems with IDN, I wanted to clear up my thoughts on=20
homograph attacks, so I sorted everything in an article which also
contains=20
what I believe to be an easy and general solution.

You can find it here:
http://www.amalthea.de/publications/homograph.pdf

Unfortunately, my free time is currently limited, so I may not be able
to=20
participate too much in any discussions on the subject. My appologies
for=20
that. But I will definitely read any feedback I receive.

Michael Roitzsch

On Mon, 7 Mar 2005, Michael Roitzsch wrote:

> Hi security community,
>
> this is my first publication I post on Bugtraq, so please be patient with me.
>
> Since the recent problems with IDN, I wanted to clear up my thoughts on
> homograph attacks, so I sorted everything in an article which also contains
> what I believe to be an easy and general solution.

Quote from your .pdf:

> I propose to present the user with a dialog showing the text to be
> validated and an input field, into which the user has to type in the given
> text again. The user is told, if both texts match precisely and what this
> means: If the typed text's internal representation matches the given text
> bit-by-bit, trust can be established. If it does not match, the user is
> told to re-check for typing errors and not to establish trust.

What you propose is the same as entering the password for each
site you visit. Yes, this IS a solution, but it is TOO DISTURBING for
users. Web surfers usually do hundreds (or thousands?) clicks per day,
and at least dozens of them are cross-site. And forcing them to type
domain's name each time is just not the way to go.

Domain names AREN'T passwords, they exist to be memorable.

Remember: users are lazy, and >90% home installs of Windows have
autologin enabled -- no usernames, no passwords. If the users are SO
lazy, they would definitely object to entering a long domain names by
their fingers.

However, there CAN be a solution for a tiny real-world subset of
"homograph attacks" problem -- the web browsers interface. My idea
is the following:

Domain names are usually written as text strings of "default
interface colors". But the browser can highlight non-ASCII
glyphs by some different background, so that even a
security-unconscious user would pay attention.

For example, if regular "URL text" colors are black-on-white, the
browser can highlight greek letters (U+0380-U+03FF) with light-blue
background, cyrillics (U+0400-U+04FF) -- with red, and all other non-ASCII
(or non-ISO8859-1) characters -- with yellow.

Such three-color highlight seems to be enough, since most
looking-identical-to-latin glyphs are in greek and cyrillc alphabets, and
the "catch-all" yellow will satisfy all other cases.


P.S. My native language is russian, so the alphabet is cyrillic. Since
cyrillic has ~30% letters looking identical to latin (but often
pronounced differently), and having different Unicode positions, it
was obvious years ago that IDN was very poorly thought. It is a big
mistake from both security and marketing points of view.

And this problem of homograpgh attacks in a general form can have no
solution at all, just because of this problem's nature. There are
cases in a real life when a russian-speaking (to be correct, a
cyrillic-based-language-speaking) person can't determine which
language some word is spelled in. For example, ask some
russian-speaker how would he or she read "nona" (that's a real name
of a hotel in Bulgaria, which causes constant fun for russian
tourists).

Just my two cents...

_________________________________________
Dmitry Yu. Bolkhovityanov
The Budker Institute of Nuclear Physics
Novosibirsk, Russia

Kevin Day wrote:

> character set(or family of languages possibly) would appear as a
> different color. Maybe make the foreign characters red, or the
> background color around each foreign character blue or something.

This actually will have to be understood by the user. While the idea to
make all characters in the unicode character set *look* different is
fine, you again will end up with the acceptance problem (wow, look at
the fancy red "a" in ebay.com, I like colours in my address bar). By the
way, using the "revert to plain punycode in address bar" approach, you'd
achieve very much the same goal but have a better user acceptance - a
weird looking URI looks much more scary than a coloured URI.

> Users using an english browser could view URLs with known "acceptable"
> characters in other languages like é, ø and other obvious differences
> with no problem, but if a user clicks on a link with a known homograph
> in another character set (like #0430 - CYRILLIC SMALL LETTER A) they get
> the scary warning of doom.

This would require one to have a database with known homographs within
the unicode charset. It's not trivial to solve since the "does character
x look like character y?" question cannot be sufficiently answered
without knowing what the font looks like that is representing the string
on users screen.

> Even when a user does whitelist a character set, they would still
> hopefully notice the obvious color change in the address bar.

Just to catch up your thoughts: It might be more convinient to define a
locale which contains all characters used in a single language (e.g.
[A-Za-z0-9äöüÄÖÜß] for German, [A-Za-z0-9áÁéÉàÀèÈâÂêÊ] for French) and
pop up a warning whenever DIFF[German, French] characters belonging to
different locales are used in the same string, e.g http://äà.com

Obviously, this will have its problems where the intention is to mix
charsets up - for example if the marketing monkey says "it's absolutely
necessary to mix up our english web site URI with chinese han symbols"
because it looks cooler.

Denis Jedig
syneticon GbR

Hi,

since a lot of people have raised doubt on the usability problems of my
solution: I am perfectly aware of them. I just don't think it is too hard to
type a domain name the first time you visit an SSL encrypted site. Some
end-user phishing checklists even advise you to type the domain you want to
visit. My solution would just enforce that.

Bet let's see if we cannot combine several solutions:

> > What would (to me) make more sense is if the browser made it more clear
> > that a homograph was being used.
> >
> > In the address bar, any character that's not from the user's language
> > character set(or family of languages possibly) would appear as a
> > different color. Maybe make the foreign characters red, or the
> > background color around each foreign character blue or something.
>
> You have come to the same idea as I did :-) (hope my post to
> Bugtraq will pass the moderation), just with a different flavor. That's a
> good sign for me, and this kind of solution seems to be not-so-hard to
> implement.

I like the solution, too. It clearly improves the current situation.

However, it has another usability problem: It won't work for the colourblind
or those using black and white only because they need high contrast. Some
users might not even have an address bar in their browser, maybe because they
got distracted by all the weird characters and disabled it.

I also see the problem that users don't look at the address bar and actually
read the address careful enough. I usually don't. A quick look at the padlock
icon is already asked too much for some users.

So why not combine all the solutions: The browser maintains a whitelist of
trusted domains. Whenever a domain is visited which offers SSL, but is not in
the whitelist, the browser will notify the user somehow (either by a dialog
or in a non-modal way, maybe a flashing padlock icon). The user can choose to
ignore the notification or follow up on it. The user is then presented with
the possibility to whitelist the domain with his choice of visually verifying
the domain name (with coloured characters) or typing it in to be safe. The
dialog's text can explain this.

Michael

--
LOAD "WIN95",8,1
RUN

>It's rather trivial to determine programatically that www.paypal.com is
>different from www.paypa1.com, but look similar. One might argue to rest
>the burden with DNS registries (why would anyone legitimately want
>paypa1.com?), but that's not likely to fly. Could it rest within the
>browser? ("Hey buddy, you're going to paypa1.com--did you mean Pay Pal?"
>or "Enable Unicode in URLs"). Perhaps with an addon ("Hey buddy, you're
>going to a restricted domain-- are you sure?"). Finally, it could rest
>with the operating system (via a variety of mechanisms).

While not exactly a solution to homograph attacks, there is an entire class
of man-in-the middle attacks (DNS poisoning, wireless Evil twin, etc) that
make use of look alike domain names as well as just redirecting the IP data
stream to a different server.

Paypal - go to URL bar, type in 'www.paypal.com', put in your username and
password and log in
Bank - go to URL bar, type in 'www.mybank.com', put in your username and
password and log in.
Bank - go to URL bar, type in 'www.mybank.com', click on the SSL login
page, put in your username and password and log in.

BZZZT - wrong! You are vulnerable to a man in the middle attack (except if
you examined the SSL certificate and/or URL prior to login in the 3rd case).
This is particularly important on a laptop if you travel to multiple
locations and wireless access points. A simple rule of thumb for less
techie computer uses is to teach them how to examine SSL certificates for
validity. Then find and bookmark the secure login page. Then if the SSL
certificate name doesn't match the browser's bookmark name, they'll get a
warning popup that the name doesn't match.

The simple rule for everyone: bookmark the secure login page of sites
where you enter your username and password. In the real world, we don't
examine each SSL certificate at every login. ....How do you get to paypal
or your online banking?

--r5Pyd7+fXNt84Ff3
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Mon, 7 Mar 2005 at 15:05:51 -0500, Scovetta, Michael V(Michael.Scovetta=
@ca.com) wrote:
>=20
> <plug>
> I've released a "fix" for the IDN vulnerability
> (www.scovettalabs.com/advisory/SCL-2005.002.txt) that basically prevents
> you from going to *any* domain that has a non-[\-A-Z0-9] character in
> it. For me, it's fine, since I'll likely never need to go to an IDN
> domain.
> </plug>

If this patch would be widely used, we'd lose the all the advantages
associated with IDN.
Maybe it's better to attack this problem on the browser side and have a
configuration switch to enable or disable IDN. We could disable it as a
"reasonable default", but those who need it, could enable it.
Upon enabling the option, a warning dialog could pop up that warns the
user about the security problems associated with IDN ("don't enable this
unless you know what you're doing" stuff).

That way the majority of the users would be safe from IDN attacks
(phishing comes to mind) and those who really want IDN would have to
click through a warning dialog telling them why enabling it may not be
such a good idea.

Just my =E2=82=AC0.02,
Sven


--=20
Encrypted mail preferred. As of Jan 27th 2005, all outgoing mail is signed.
GPG keyID: 0x66A13305
GPG key fingerprint: 5B8C 97A2 20C4 E578 CDEB 71C9 23CA 0681 66A1 3305
GPG key URL: http://werner.sytes.net/~svenniboy/gpg_pubkey.asc

--r5Pyd7+fXNt84Ff3
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.0 (GNU/Linux)

iD8DBQFCLfP7I8oGgWahMwURAkDnAKC9L6km0BRtiP0+TTiVtw qaD+TwBgCcDzjO
C4ZXjECStRPbB/TtyGP9To8=
=bvu+
-----END PGP SIGNATURE-----

--r5Pyd7+fXNt84Ff3--

Sven Putteneers wrote:

> If this patch would be widely used, we'd lose the all the advantages
> associated with IDN.

I think that was the point.

IDN was not a very clever idea from the start -- it breaks the "don't
allow the obvious to not be what it appears to be" (aka "don't surprise
the user", etc, etc) rule which is one of the very most important rules
of any kind of technology/human interface. When you do break that rule
you get all kinds of "obvious" problems down the track, including very
many that should have been obvious at the outset, to the designer of
the system or functionality that did the breaking.

Such stupid and eternally regrettable design decisions have often been
strongly commercially motivated.

> Maybe it's better to attack this problem on the browser side and have a

Given IDN would seem to be here to stay, I'd say that will be the only
place we can attack it...

> configuration switch to enable or disable IDN. We could disable it as a
> "reasonable default", but those who need it, could enable it.
> Upon enabling the option, a warning dialog could pop up that warns the
> user about the security problems associated with IDN ("don't enable this
> unless you know what you're doing" stuff).
>
> That way the majority of the users would be safe from IDN attacks
> (phishing comes to mind) and those who really want IDN would have to
> click through a warning dialog telling them why enabling it may not be
> such a good idea.

Such warnings have far from sufficient efficacy. Much history shows
that the folk who will most likely "stupidly ignore" such warnings are
precisely the ones that would derive (most) benefit from the warnings
_had they heeded them_ (i.e. the folk who really need this protection
are the ones that will turn it off). The "let's pop up a warning
message" approach to truly hard problems such as this is a commonly
seen approach that shows the developer's total lack of understanding
_and_ caring about the actual problem.

Without having thought too hard about all this, a better browser-side
solution may be to not allow domain names with a mixture of ASCII and
IDN characters (I mean to the left of the unavoidably ASCII (??) top
level country, .com, .mil, .org, .net, etc domain name components). If
you have a Korean or Japanese or Mandarin or whatever domain name, then
there should be no need for any ASCII characters in it. There may be
problems with this idea with Central European names, where much of the
ASCII character set is employed along with a few special characters,
and with domain names that incorporate numerals. If IDN can be used to
encode characters from the ASCII character set too then these problems
are moot, but we end up back where we started in terms of mixed
ASCII/IDN-only chars being the "problem".

Of course, not allowing mixed ASCII/IDN does not entirely remove the
problem of "IDN-spoofing" -- for most suitably long domain names
(perhaps those with more than five _different_ caracters?) it is
probably a safe bet that there will not be a suitable set of IDN
homographs* possible to spoof your domain name, but for shorter ones...


* Being the semi-pedant that I am, "homograph" was always the wrong
term for these IDN spoofing tricks. A homograph is a pair of words (or
presumably more) that are spelt the same but have different meanings.
What we are talking about here are two (or more) words that are spelt
differently but look the same -- perhaps "pseudograph", if not the
right word, is certainly better.)




--
Nick FitzGerald
Computer Virus Consulting Ltd.
Ph/FAX: +64 3 3267092

At 00:48 09/03/2005, Nick FitzGerald wrote:
> > Maybe it's better to attack this problem on the browser side and have a
>
>Given IDN would seem to be here to stay, I'd say that will be the only
>place we can attack it...

Personally, I think the best place to attack it is at the registry -
unfortunately most of those are bound by commercial motivation instead of
trying to be good citizens, or help Internet users in general, so it might
be harder to change their behaviour than change browser behaviour.

My proposal would be:

1) IDNs only allowed on ccTLDs (not gTLDs). After all , the whole point of
IDNs is to have a domain name in the locally readable script to target
people within your own region/nation/etc. gTLDs are to have domains to
target people globally. I see no purpose (other than vanity) to having an
IDN in a gTLD .

2) IDNs should only be allowed to consist of a single character set - be
that Latin, Western European, Japanese, Cyrillic etc.

3) A ccTLD should only allow IDNs in their local character set(s). So, you
couldn't have a cyrillic IDN on a .us domain, and you couldn't have a greek
IDN on a .ru domain.

(4) A domain registry's DRS system should take into account
homograph/pseudograph attacks.

(5) Possibly any domains containing only characters which are graphically
equivalent to latin characters should not be allowed, but I'm not sure of
this one.

I think if IDNs followed these rules they would still keep most of their
benefit, but also make it MUCH harder to have a homograph/pseudograph attack.

(1) is needed as it's still possible to make up certain words using
characters from the cyrillic and/or greek (and possibly others) character
sets that look like words from the latin character set. Having this rule
limits the scope of these possible attacks to people in Russian or Greece

(2) is needed for (hopefully) obvious reasons

(3) is needed for the same reason as (1)

(4) Obvious

This leaves (AFAICS) the only possible attacks being in Russia or Greece
(and possibly others with similar character sets) to a very few
domains. For instance EBAY.RU would still be possible using 0415, 0412,
0410, 0423 as well as 0045, 0042, 0041, 0059.

But, there is only this single combination of cyrillic characters which
could resemble the 'proper' EBAY.RU. If you don't have rule (2), then you
could have lots of different combinations, eg, 0045, 0412, 0041, 0059 etc.
So, having rule (2) means that eBay could register (or use DRS to regain) a
single extra domain to protect themselves and their customers, instead of 16.

Rule (5) would stop even this, but it could cause problems with legitimate
Russian or Greek words which contain only Latin characters. This really
needs behavioural investigation. For instance, if a Greek Internet user saw
WWW.KAPPA.GR (or www.<another greek word which can have greek or latin
letters), would they type in 'KAPPA' in Greek letters, or in Latin letters?
I suspect they'd type it in latin, in which case rule (5) would be OK, but
if they'd type it in greek, then rule (5) would not be OK.

I think limiting the protection to browsers has several problems:
- it stops IDNs from having most of their usefulness
- it makes browser development more complicated due to no fault of theirs
- in countries where IDNs are widely used, they're still open to attack as
they'd *have to* enable IDNs to be able to use the Internet adequately
- it doesn't just affect browsers, it affects email clients, chat programs,
ftp programs, news readers, etc etc etc

Even if my 'rules' were optional, well behaved registries could use them,
and advertise they use them, then browsers could warn (or un-IDN-ise) IDNs
from other registries, but show IDNs from the well behaved registries in
their proper character set.

Paul VPOP3 - Internet Email Server/Gateway

support@pscs.co.uk http://www.pscs.co.uk/

--==_Exmh_1110920971_4720P
Content-Type: text/plain; charset=us-ascii

On Tue, 15 Mar 2005 12:27:09 +0100, Riccardo Murri said:

> I would rather suggest that the string comparison function used in IDN
> takes "homograph caracters"[1] into account: just like the current DNS
> considers 'a' == 'A', the IDN DNS should consider "LATIN SMALL LETTER
> a" == "CYRILLIC SMALL LETTER a" == "CYRILLIC CAPITAL LETTER A" ==
> "GREEK CAPITAL LETTER A"[2], and similarly for the other homograph chars.

The problem here is that defining what characters are "similar" enough to be
homographs is a very fuzzy concept. Glyphs that may look similar on a 1600x1200
display on my laptop may not look similar when the *same exact* 1600x1200 is
being displayed on the 21" monitor hanging off my docking station. Also, the
point size in use may matter - that macron that's easily visible at 15pt may be
invisible at 11pt. Bitmap and outline fonts will have different behaviors
in this regard, and anti-aliasing adds another twist to the equations....

And even if you program all *that* sort of knowledge in, there's no way in the
near future that the software will know if I'm wearing my contacts or if I'm
wearing my glasses, and if I'm wearing contacts, if I happen to have my reading
glasses handy.....


--==_Exmh_1110920971_4720P
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.0 (GNU/Linux)
Comment: Exmh version 2.5 07/13/2001

iD8DBQFCN08LcC3lWbTT17ARAsxoAKDPoJo9qXGokGtQAeETHy P6BpxIXgCgl8Iu
Fj2USpwPFj9sSudy+imJfb0=
=IEoR
-----END PGP SIGNATURE-----

--==_Exmh_1110920971_4720P--