Non-English Domain Names Likely Delayed

Mailman List Mirror (Read Only)
1

Already, some 21 TLDs are whitelisted, including .cn, .tw, a number
of European ccTLDs, .museum, and .info. Any other registrars who
want to be supported can simply E-mail Gerv at the Mozilla
Foundation, or his Opera counterpart, and give them a pointer to
their anti-spoofing rules.

I don't think it's a good idea to introduce a system with a known
vulnerability and try and work around it by having some people agree
they'll police the exploit. No doubt the people protecting us
will be tempted to exploit it themselves by trying to sell
the spoofs to the spoofed domain owner as essential international
branding (.mobi, yeah. .com is shorter and people should learn
about content negotiation to present suitable content to mobiles,
no need to buy your domains all over again)

If this goes ahead the browser needs a default on button for
"please don't expose me to this spoofing attack"

brandon

2

Brandon Butterworth wrote:

Already, some 21 TLDs are whitelisted, including .cn, .tw, a number
of European ccTLDs, .museum, and .info. Any other registrars who
want to be supported can simply E-mail Gerv at the Mozilla
Foundation, or his Opera counterpart, and give them a pointer to
their anti-spoofing rules.
     
I don't think it's a good idea to introduce a system with a known
vulnerability and try and work around it by having some people agree
they'll police the exploit. No doubt the people protecting us
will be tempted to exploit it themselves by trying to sell
the spoofs to the spoofed domain owner as essential international
branding (.mobi, yeah. .com is shorter and people should learn
about content negotiation to present suitable content to mobiles,
no need to buy your domains all over again)

If this goes ahead the browser needs a default on button for
"please don't expose me to this spoofing attack"

brandon

Unfortunately, the problem is inherent in human writing systems. Consider rnicrosoft.com and paypaI.com.

The good news is that fairly simple homograph rules can be applied to collapse the namespace into visually distinct labels: see TR #36. See also https://bugzilla.mozilla.org/show_bug.cgi?id=279099 for a lengthy group discussion of the issues involved.

As a side-effect of this, implementing either a blocking bundling or inclusive bundling policy has the effect of precluding a registry from selling potential spoofs to others. The former requires no change to existing software, apart from a check at name registration time; the latter requires either the generation of huge zonefiles, or a few lines of code and a ~128kbyte static lookup table to be added to DNS server software: see RFC 3743 for more detail than you ever wanted to know about bundling.

Neither is beyond the wit of man, particularly given commercial pressure from registry customers.

Neil
(my personal views only, not that of any organization)

3

The registry customers don't pay the bills of ICANN and the governments who maintain the ccTLDs. The registries pay those bills, and they get their money (in part) from those who would intentionally create confusing domain names of the sort you would want to prevent.

  It's like MCI registering 1-800-OPER-ATER because 50% of the people in the US are illiterate and cannot spell, and don't know that they really meant to use the AT&T service over on 1-800-OPER-ATOR. Why do you think AT&T changed to 1-800-CALL-ATT?

  You may get some TLD operators to sign up for service with you, but I don't think you're going to get even a simple majority. Moreover, without official approval and coordination through IETF/IANA/ICANN, I don't think you're going to get a sizable minority.

  You seem to have the technical side down reasonably well. What you need to do now is to work on putting that process into the correct place within the context of Internet governance, and get that out of the hands of people who are involved in creating specific products that use the scheme in question.

  Having this coordinated by the right group isn't going to change the minds of the registry operators who want to make the extra bucks, and it sure as hell won't change the minds of any of the alternative root operators -- None of them would be in business at all if it weren't for the network abusers.

  But you'd be more likely to get more of the legitimate TLD operators that would otherwise remain on the fence.

4

    The registry customers don't pay the bills of ICANN and the governments who maintain the ccTLDs.

Governments? You have some strange ideas about ccTLDs.

The registries pay those bills, and they get their money (in part) from those who would intentionally create confusing domain names of the sort you would want to prevent.

That's why it's good that browser vendors are keeping an eye on this.

    You seem to have the technical side down reasonably well. What you need to do now is to work on putting that process into the correct place within the context of Internet governance,

Let the lawyers rule the world? Yeah right, that will help.

When the "governance" types get it right, sure, set up all the browsers to take their cue. In the mean time, let's do what works today. Ultimately, the user should be in control (like I am with my named.root file) but the vendors should set good defaults to help the users who can't do this themselves.

5

     The registry customers don't pay the bills of ICANN and the
governments who maintain the ccTLDs.

Governments? You have some strange ideas about ccTLDs.

  Okay, fine -- government-authorized organizations, then. Such as SIDN for .nl, DNS.be for .be, etc.... Like Verisign, they may well have to get their contracts renewed with the government. Like Verisign, the people who pay the bills are not the end-user consumers of e-mail addresses and web browsers, and many of the bill-payers are likely to be the sort of people who would want to encourage confusion.

That's why it's good that browser vendors are keeping an eye on this.

  We definitely don't want the registries being the watchers in this case, but I also don't think we want to have a mish-mash hodge-podge of twelve zillion different solutions, each of which is being hard-coded into various different applications. This is an area where we need to have some standards that can be broadly applied to all Internet and Internet-enabled applications, including web browsers.

  You wouldn't want Ford setting standards for roads, even if they could create an agreement with GM. And you don't want each country setting their own universal standards, either. That way lies madness.

Let the lawyers rule the world? Yeah right, that will help.

  Excuse me? How on God's Bloody Green Earth did you pull that out of your @$$?

When the "governance" types get it right, sure, set up all the browsers
to take their cue. In the mean time, let's do what works today.

  Fine, so we get different implementations in every single browser and MUA and every other Internet-enabled program. You get what you want.

Ultimately, the user should be in control (like I am with my named.root
file) but the vendors should set good defaults to help the users who
can't do this themselves.

  You're a customer of an ISP. You know nothing about how to run your own nameserver. Just how exactly do you expect to have control over your own named.root?

  If you're not a programmer with direct commit access to Mozilla and Opera, just how exactly do you expect to have any control over this process?

  Your personal example doesn't count here. What counts is what the average user can do/is reasonably capable of.

6

Isn't someone more eloquent than I going to point out that that spending
a lot of effort eliminating homographs from DNS to stop phishing is a
security measure on par with cutting cell service to underground trains
to prevent bombings? It focuses on one small vulnerability that phishers
exploit, and "fixing" this one vulnerability just may make things worse.
It wastes resources that could go to coming up with a *real* solution, and
it may provide a false sense of security. There are dozens of ways we know
of, and probably more that lie undiscovered, to exploit vulnerabilities in
DNS, browsers, and in human nature to conduct phishing.

Worrying about homographs is probably something about which we should let
the trademark lawyers get there undies in a bunch (knowing ICANN, that
may very well be what's driving this, not phishing worries) while the IT
security community concerns itself with a usable, and actually secure,
end-to-end security model for e-commerce.

7

     The registry customers don't pay the bills of ICANN and the
governments who maintain the ccTLDs.

Governments? You have some strange ideas about ccTLDs.

    Okay, fine -- government-authorized organizations, then. Such as SIDN for .nl, DNS.be for .be, etc.... Like Verisign, they may well have to get their contracts renewed with the government.

Maybe one day I'll tell you about the early days of SIDN. No government in sight. I know this has changed a bit, but it's mostly rubber stamping what was happening already. I'm fairly sure it's the same way for most ccTLDs.

Like Verisign, the people who pay the bills are not the end-user consumers of e-mail addresses and web browsers, and many of the bill-payers are likely to be the sort of people who would want to encourage confusion.

I don't believe the major TLDs with million+ names registered are short sighted enough to think it's a good idea to encourage confusion.

That's why it's good that browser vendors are keeping an eye on this.

    We definitely don't want the registries being the watchers in this case, but I also don't think we want to have a mish-mash hodge-podge of twelve zillion different solutions, each of which is being hard-coded into various different applications.

Apparently there's only one way that really works, so everyone will be doing the same thing, save for some details maybe.

This is an area where we need to have some standards that can be broadly applied to all Internet and Internet-enabled applications, including web browsers.

Too bad standards don't crop up over night. But it would be helpful if the IETF (or another standards organization?) would do something here.

    You wouldn't want Ford setting standards for roads, even if they could create an agreement with GM. And you don't want each country setting their own universal standards, either. That way lies madness.

Remember the Bell standards? ANSI, DIN? You have to with what works, especially in security where the cost of doing it wrong or delaying the solution can be very high.

Let the lawyers rule the world? Yeah right, that will help.

    Excuse me? How on God's Bloody Green Earth did you pull that out of your @$$?

Ok then, what else is the dominant profession amongst (wannabe) internet governance types?

Ultimately, the user should be in control (like I am with my named.root
file) but the vendors should set good defaults to help the users who
can't do this themselves.

    You're a customer of an ISP. You know nothing about how to run your own nameserver. Just how exactly do you expect to have control over your own named.root?

Buy some books at oreilly.com?

    If you're not a programmer with direct commit access to Mozilla and Opera, just how exactly do you expect to have any control over this process?

Hopefully they make this stuff user configurable. This stuff is a lot like SSL certificates that come with browsers. You can manage those yourself if you jump through the hoops.

It's not so much that many people will actually do this, but the fact that users can vote with their feet keeps the people in control down the chain honest. (Well, more honest than they would be otherwise, at least.)

You can't have an effictive dictatorship when people are free to move to the next country.

8

If you make a bunch of assumptions (SSL certificate chain is ok, binary is trustworthy, etc) you can be sure that when it says https://www.blah.com/ in your browser, you're actually communicating with the entity holding the name www.blah.com in a secure way. So when something that looks exactly like www.blah.com is in fact different from www.blah.com, that's a pretty big deal because it breaks the whole system. So how would fixing this make things worse? And what else should we be doing instead?

9

Iljitsch van Beijnum wrote:

...snip...

    If you're not a programmer with direct commit access to Mozilla and Opera, just how exactly do you expect to have any control over this process?

Hopefully they make this stuff user configurable. This stuff is a lot like SSL certificates that come with browsers. You can manage those yourself if you jump through the hoops.

It's not so much that many people will actually do this, but the fact that users can vote with their feet keeps the people in control down the chain honest. (Well, more honest than they would be otherwise, at least.)

You can't have an effictive dictatorship when people are free to move to the next country.

I can't speak for Opera's implementation, but the Mozilla folks have made their implementation eminently configurable, using the standard configuration variable mechanism, with one variable for each domain to be whitelisted.

That means it can be altered by any of:
* editing the human-readable configuration files
* using the interactive about:config interface to edit the files from within the browser
* loading a third-party browser extension

-- Neil

10

Maybe one day I'll tell you about the early days of SIDN.

  I've had some pretty extensive conversations with Jaap. I came pretty close to working for him, even though I'm in Brussels and the job is in Amsterdam. I've had pretty extensive conversations with a number of people from what is now Stichting NLnet, and heard some interesting stories.

  However, I don't see that this has any bearing whatsoever on the way that TLD registries operate today. Certainly no more than old stories about how things used to be with Jon Postel as the Benevolent Dictator.

                                                            No government
in sight. I know this has changed a bit, but it's mostly rubber stamping
what was happening already.

  Key word, "was".

                              I'm fairly sure it's the same way for most
ccTLDs.

  Maybe it was. It's not that way anymore.

I don't believe the major TLDs with million+ names registered are
short sighted enough to think it's a good idea to encourage confusion.

  They know who really pays the bills, and those customers will make sure that they know that they shouldn't work too hard to eliminate confusion. There may be some who take a more pro-active view, but I fear that they will be in the minority.

Apparently there's only one way that really works, so everyone will be
doing the same thing, save for some details maybe.

  I'll believe that when I see it.

Remember the Bell standards? ANSI, DIN? You have to with what works,
especially in security where the cost of doing it wrong or delaying
the solution can be very high.

  There's also a high cost in setting things in concrete before the foundation is ready.

Ok then, what else is the dominant profession amongst (wannabe)
internet governance types?

  I think most of the people in the IETF are techno-geeks, although some are probably systems administrators, some are systems programmers, some are network administrators, etc.... As to which of those is dominant, I have no idea.

  If you're talking about ICANN, well they're part of the problem -- you don't want them to be the watchers, either.

  In the ITU, I imagine that there are a few lawyers involved, but most of the people in question are probably telephone wire-heads.

  Got any others?

Hopefully they make this stuff user configurable. This stuff is a lot
like SSL certificates that come with browsers.

  Even if it is configurable in one browser doesn't mean that it will be in any other. And just because it's configurable in a browser doesn't mean that the zillions of other Internet-enabled applications will do the same.

  Regardless, the Rule of Defaults says that something like 99.999% of them will take whatever is shipped.

It's not so much that many people will actually do this, but the fact
that users can vote with their feet keeps the people in control down the
chain honest. (Well, more honest than they would be otherwise, at least.)

  But where do they run? If everyone has their own implementation, presumably many of them will have minor or major incompatibilities. If all the buildings around you are falling down for one reason or another, how do you choose which one to live in?

You can't have an effictive dictatorship when people are free to move to
the next country.

  Hmm. Seems to me I've heard others say that in the past, in defense of some rather unsavoury actions that they've undertaken.

  If you want to cast yourself as a good guy and everyone else as a bad guy, you might want to choose different phraseology.

11

Iljitsch van Beijnum wrote:

Isn't someone more eloquent than I going to point out that that spending
a lot of effort eliminating homographs from DNS to stop phishing is a
security measure on par with cutting cell service to underground trains
to prevent bombings? It focuses on one small vulnerability that phishers
exploit, and "fixing" this one vulnerability just may make things worse.

If you make a bunch of assumptions

Well, that's just it. There are a whole ton of assumptions here.
That the name that pops up in the navi-bar kinda-maybe-looks-sorta
like the site you think it should is just one of many and may
not even be the weakest.

> (SSL certificate chain is ok,

Yeah, make sure Verisign isn't issuing "Microsoft" certificates
to someone who isn't Microsoft again. And hey, can we play
homograph games inside of X.509 certs too!? Fun!

> binary is trustworthy, etc)

Plus, you have to trust DNS, which means you have to trust:

   1) the root
   2) the gTLD
   3) the authorative servers for the domain

And for 99% of the users out there,

   4) the caching servers for their ISP/employer/other access
  provider

That is, trust that they are not actively malicious nor have been
exploited by some new or old cache poisoning trick, had a bogus
registrar switch (like Panix's recent experience), etc.

you can be sure that when it says https:// www.blah.com/ in your browser, you're actually communicating with the entity holding the name www.blah.com in a secure way. So when something
that looks exactly like www.blah.com is in fact different from www.blah.com, that's a pretty big deal because it breaks the whole system.

Assuming the system works. SSL doesn't really work now since
so many users reflexively click through warnings about bad
certificates.

And while we're at it, does any of this fix whether any of
the following,

  www.blah-inc.com
  www.blah.net
  www.blah.biz

Might trick a user into thinking he's connected to the same
entity that owns www.blah.com?

> So how would fixing this make things worse?

Wrong question. How will fixing this one problem make things any
better? If almost none of the phishing emails I get now bother
to play these kinds of games today, how much does this really help?
Yeah, if it's easy, go ahead, but as the mere existence of this
thread seems to indicate this is not an easy problem. I worry that
like many of the other spam-related problems while we have a lot of
very smart people like yourself thinking hard about how to prevent
abuse, we may just be rearranging the deck chairs on the Titanic.
It may be time to head for the lifeboats, let this ship go down, and
start building a new, better boat now that we better understand the
threats.[0]

> And what else

should we be doing instead?

Many things, perhaps the two most important "we" can do:

   1) Pounding it into the users that you don't ever trust what it
  says in the navigation bar unless you typed it there yourself.
  Corrorlaries: (a) When following links on webpages, your level
  of trust should only be that of the least trusted page in the
  chain of links. (b) NEVER EVER, EVER, EVER trust a link in an
  unsigned email.
   2) Pounding it into merchants, banks, etc., to make sure they never
  ask their customers to violate (1).

But sorry, I do not have all of the answers either.

[0] Perhaps a better analogy is that by "cleaning up" DNS, we are
trying to prevent the iceburgs. We should be letting the indvidual
merchants, banks, and other secure sites, the ships, make their
own schemes for avoiding them. We could be helping them build stronger
ships, something better than today's SSL, and mapping out where the
iceburgs are, figuring out where they need to balance convenience
versus security, than trying to clear the seas of all possible hazards.

12

> Like Verisign, the people who pay the bills are not the end-user
> consumers of e-mail addresses and web browsers, and many of the
> bill-payers are likely to be the sort of people who would want to
> encourage confusion.

I don't believe the major TLDs with million+ names registered are
short sighted enough to think it's a good idea to encourage confusion.

This would be the same TLDs that don't censure registrars with a long track
record of registering domains for known phishers and spammers and the like, right?

> You're a customer of an ISP. You know nothing about how to run
> your own nameserver. Just how exactly do you expect to have
> control over your own named.root?

Buy some books at oreilly.com?

I'd cue a Randy Bush audio clip, if only I knew that only the offender's ISP's
phone would ring. Unfortunately, this isn't the case....

What percent of the Joe Sixpacks out there could sucessfully manage their
named.root given a copy of 'DNS for Idiots' without generating at least one
trouble ticket?

Also, what do the experiences of people who had to deal with getting themselves
out of 69/8 bogon filters or thousands of different SMTP blacklists tell us about
the wisdom of having a large number of these sorts of things sitting where
end users can mangle-and-forget? Remember - most land mines are detonated
by civilians long after the war is over.....

13

What percent of the Joe Sixpacks out there could sucessfully manage their
named.root given a copy of 'DNS for Idiots' without generating at least
one trouble ticket?

uh, i have been managing domains for a looong while, manage half
a dozen cctld registries, ... and i only make a mistake once a
week or so.

we're all bozos on this bus. except brad, of course.

randy

14

If you make a bunch of assumptions

[...]

Plus, you have to trust DNS, which means you have to trust:

  1) the root
  2) the gTLD
  3) the authorative servers for the domain

And for 99% of the users out there,

  4) the caching servers for their ISP/employer/other access
    provider

Actually, you don't. If the DNS provides false information, the public key crypto will catch this. Sure, you won't be able to communicate, but you can't be fished that way.

you can be sure that when it says https:// www.blah.com/ in your browser, you're actually communicating with the entity holding the name www.blah.com in a secure way. So when something
that looks exactly like www.blah.com is in fact different from www.blah.com, that's a pretty big deal because it breaks the whole system.

Assuming the system works. SSL doesn't really work now since
so many users reflexively click through warnings about bad
certificates.

There is no cure for stupidity... And I'm not even sure it's really stupidity: in their own twisted way, these users behave rationally because the energy to stay safe isn't worth keeping away the bad consequences to them. This of course changes when their online banking account is raided.

And while we're at it, does any of this fix whether any of
the following,

    www.blah-inc.com
    www.blah.net
    www.blah.biz

Might trick a user into thinking he's connected to the same
entity that owns www.blah.com?

I don't see why this would need to be "fixed". We're not talking about 5 year olds, people need to be able to cross the road without someone holding their hand.

> So how would fixing this make things worse?

Wrong question. How will fixing this one problem make things any
better?

Simple: the system then performs as designed again. All the other problems are more or less under the user's control.

If almost none of the phishing emails I get now bother
to play these kinds of games today, how much does this really help?

And burglars also manage to get inside your house even though you lock the door. So better not lock the door then?

Yeah, if it's easy, go ahead, but as the mere existence of this
thread seems to indicate this is not an easy problem. I worry that
like many of the other spam-related problems while we have a lot of
very smart people like yourself thinking hard about how to prevent
abuse, we may just be rearranging the deck chairs on the Titanic.

That is such crap, and it's exactly this attitude that makes it possible for spam to persist. When confronted by an apparently intractable problem, in very many cases it helps to solve the parts that can be solved and then have another look at the remaining problem. More often than not it doesn't look as intractable any more.

should we be doing instead?

Many things, perhaps the two most important "we" can do:

  1) Pounding it into the users that you don't ever trust what it
    says in the navigation bar unless you typed it there yourself.
    Corrorlaries: (a) When following links on webpages, your level
    of trust should only be that of the least trusted page in the
    chain of links.

If this is true, it means a failure on the part of the browser. I don't think we should live with that but get ourself better browsers.

(b) NEVER EVER, EVER, EVER trust a link in an
    unsigned email.

Haha. I talked to a CERT guy a while ago. They had a service where they send out dumbed down warnings to regular users (not sysadmins or whatever). I asked him why they didn't use S/MIME to sign their mail. "That confuses people." Ok then. If people in the security business (how I hate the fact that it's a business these days!) don't even want to use the tools that are available, rational thought breaks down. (Although I have to admit that it DOES look confusing in popular Windows email clients.)

  2) Pounding it into merchants, banks, etc., to make sure they never
    ask their customers to violate (1).

Expansion of 1: don't trust any unsollicited communication. This includes all incoming email (unless it's signed but it never is) and phone calls. (Law enforcement at your door? How do I know those badges are real?) Never give out your password to ANYONE, EVER.

But sorry, I do not have all of the answers either.

(-:

[0] Perhaps a better analogy is that by "cleaning up" DNS, we are
trying to prevent the iceburgs. We should be letting the indvidual
merchants, banks, and other secure sites, the ships, make their
own schemes for avoiding them. We could be helping them build stronger
ships, something better than today's SSL, and mapping out where the
iceburgs are, figuring out where they need to balance convenience
versus security, than trying to clear the seas of all possible hazards.

No, what's needed is that systems don't have glaring holes. Email is a joke, anyone can send messages with any "From" line that they want. Credit cards are a joke, anyone who works in a store can copy numbers and then use those online. The trouble with these two is that people have been using them as-is for so long that they don't want to give up the convenience of the insecurity. So at some level this is working for people, or they wouldn't be using it.

15

uh, i have been managing domains for a looong while, manage half
a dozen cctld registries, ... and i only make a mistake once a
week or so.

  If you're achieving those numbers, you're doing a lot better than 99.9999999% of the rest of the world.

we're all bozos on this bus. except brad, of course.

  Oh no, I'm a bozo too. I make fat-finger mistakes. Leave off trailing dots. And all other sorts of stupidity that I should know better than to do. But then I'm human, and mistakes are what humans do best.

  But I think Valdis said it best:

                             Remember - most land mines are
    detonated by civilians long after the war is over.....

16

And for 99% of the users out there,

   4) the caching servers for their ISP/employer/other access
     provider

Actually, you don't. If the DNS provides false information, the public
key crypto will catch this. Sure, you won't be able to communicate, but
you can't be fished that way.

  What public key crypto are you talking about? You seem to think that something like DNSSEC is in wide use throughout the world, which is a very strange notion for someone to have when they damn well should know better.

I don't see why this would need to be "fixed". We're not talking about
5 year olds, people need to be able to cross the road without someone
holding their hand.

  You're on a slippery slope here. At what point do you think that you can stop protecting the users? How do you justify that?

17

[need to trust the DNS system]

Actually, you don't. If the DNS provides false information, the public
key crypto will catch this. Sure, you won't be able to communicate, but
you can't be fished that way.

    What public key crypto are you talking about?

The public key crypto that powers the authentication in SSL.

I don't see why this would need to be "fixed". We're not talking about
5 year olds, people need to be able to cross the road without someone
holding their hand.

    You're on a slippery slope here. At what point do you think that you can stop protecting the users? How do you justify that?

I justify it because "protecting" users agains the fact that similar looking/sounding names actually map to completely different things ultimately can't be done, so it's better to not do it at all so users get burned by relatively harmless examples of this phenomenon (www.gougle.com and the like) so they understand it and foster the appropriate level of distrust.

18

     What public key crypto are you talking about?

The public key crypto that powers the authentication in SSL.

  But that has nothing to do with the DNS. Moreover, mikerowesoft.com would presumably have an SSL certificate issued to mikerowesoft.com and which claimed only that it was mikerowesoft.com and not microsoft.com. The SSL certificate would check out completely, and still have absolutely nothing whatsoever to do with the DNS, cache pollution/poisoning, etc....

     You're on a slippery slope here. At what point do you think that
you can stop protecting the users? How do you justify that?

I justify it because "protecting" users agains the fact that similar
looking/sounding names actually map to completely different things
ultimately can't be done, so it's better to not do it at all so users
get burned by relatively harmless examples of this phenomenon
(www.gougle.com and the like) so they understand it and foster the
appropriate level of distrust.

  Actually, that's a statement that I can agree with.

  My point was that, if you're going to try to protect the users against homophone/homograph attacks, you need to do it in a standardized way.

  Morover, the standards for controlling that need to be held by separate entities from those who are creating the tools which will implement those standards -- witness Microsoft's recent downgrading of Claria/Gator as a malware vendor, simply because they're looking at buying the company.

19

The public key crypto that powers the authentication in SSL.

    But that has nothing to do with the DNS.

:slight_smile: That's exactly the point: DNS tricks won't buy you anything (except denial of service) in the presence of SSL.

"protecting" users agains the fact that similar
looking/sounding names actually map to completely different things
ultimately can't be done, so it's better to not do it at all so users
get burned by relatively harmless examples of this phenomenon
(www.gougle.com and the like) so they understand it and foster the
appropriate level of distrust.

    Actually, that's a statement that I can agree with.

Excellent.

    My point was that, if you're going to try to protect the users against homophone/homograph attacks, you need to do it in a standardized way.

And my point is, that in the absence of a standardized way a non-standardized way will do temporarily.

    Morover, the standards for controlling that need to be held by separate entities from those who are creating the tools which will implement those standards -- witness Microsoft's recent downgrading of Claria/Gator as a malware vendor, simply because they're looking at buying the company.

Sure, why not. I'm not convinced it will help, though. (Giving in to the conspiracy theorists doesn't work: they'll just think it's a conspiracy.)

20

Isn't someone more eloquent than I going to point out that that spending
a lot of effort eliminating homographs from DNS to stop phishing ...

I sat in on some of the discussion at ICANN in Lux, and I simultaneously
heard that the problem is fundamentally insoluble, but ICANN has to do
something about it anyway, which makes no sense to me.

I see two reasons that it's a waste of time to worry about homographs.
One is that there's so many approximate homographs even in "simple"
languages like English (O and 0, I and l and 1, etc.) that you can't
possibly strike them all. The other is that even if you rule out all
variants of, say, citibank.com, you're still going to have names like
citibank-account.com (which is not Citibank) and cyota.net (which
isn't Citibank either, but runs Verified by Visa mail on behalf of
lots of real banks.)

There are plausible counterattacks to phishes, with branded signatures
from a small set of well-known third parties at the top of my list,
but eliminating homographs is fixing the leaks in a sieve one hole at
a time.

R's,
John