Re: Non-English Domain Names Likely Delayed
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
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)
At 3:22 PM +0100 2005-07-18, Neil Harris wrote:
Neither is beyond the wit of man, particularly given commercial pressure from registry customers.
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. -- Brad Knowles, <brad@stop.mail-abuse.org> "Those who would give up essential Liberty, to purchase a little temporary Safety, deserve neither Liberty nor Safety." -- Benjamin Franklin (1706-1790), reply of the Pennsylvania Assembly to the Governor, November 11, 1755 SAGE member since 1995. See <http://www.sage.org/> for more info.
On 18-jul-2005, at 16:42, Brad Knowles wrote:
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.
At 5:03 PM +0200 2005-07-18, Iljitsch van Beijnum wrote:
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. -- Brad Knowles, <brad@stop.mail-abuse.org> "Those who would give up essential Liberty, to purchase a little temporary Safety, deserve neither Liberty nor Safety." -- Benjamin Franklin (1706-1790), reply of the Pennsylvania Assembly to the Governor, November 11, 1755 SAGE member since 1995. See <http://www.sage.org/> for more info.
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. -- Crist J. Clark crist.clark@globalstar.com Globalstar Communications (408) 933-4387
On 18-jul-2005, at 23:43, Crist Clark 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 (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?
Iljitsch van Beijnum wrote:
On 18-jul-2005, at 23:43, Crist Clark 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. -- Crist J. Clark crist.clark@globalstar.com Globalstar Communications (408) 933-4387
On 19-jul-2005, at 1:43, Crist Clark wrote:
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.
At 10:31 AM +0200 2005-07-19, Iljitsch van Beijnum wrote:
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? -- Brad Knowles, <brad@stop.mail-abuse.org> "Those who would give up essential Liberty, to purchase a little temporary Safety, deserve neither Liberty nor Safety." -- Benjamin Franklin (1706-1790), reply of the Pennsylvania Assembly to the Governor, November 11, 1755 SAGE member since 1995. See <http://www.sage.org/> for more info.
On 19-jul-2005, at 12:11, Brad Knowles wrote: [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.
At 12:46 PM +0200 2005-07-19, Iljitsch van Beijnum wrote:
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. -- Brad Knowles, <brad@stop.mail-abuse.org> "Those who would give up essential Liberty, to purchase a little temporary Safety, deserve neither Liberty nor Safety." -- Benjamin Franklin (1706-1790), reply of the Pennsylvania Assembly to the Governor, November 11, 1755 SAGE member since 1995. See <http://www.sage.org/> for more info.
On 19-jul-2005, at 15:03, Brad Knowles wrote:
The public key crypto that powers the authentication in SSL.
But that has nothing to do with the DNS.
:-) 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.)
Brad Knowles wrote:
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.
See Unicode Technical Report 36, rev 3. http://www.unicode.org/reports/tr36/ for a thorough treatment of the issues involved, under the auspices of the vendor-neutral Unicode Consortium. See in particular Appendix B, Confusables Detection, and Appendix F, Country-Specific IDN Restrictions. Finally, I just thought that I should point out that this problem potentially exists in internationalizing _any_ protocol that uses human-readable identifiers, not just DNS. -- Neil ** **
Brad Knowles wrote:
At 10:31 AM +0200 2005-07-19, Iljitsch van Beijnum wrote:
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.
He is making the assumption that if someone has got a cert for, www.blah.com From one of the "well known" CAs, no one else can get one from one of the well-known CAs for that same name. -- Crist J. Clark crist.clark@globalstar.com Globalstar Communications (408) 933-4387
Iljitsch van Beijnum wrote:
On 19-jul-2005, at 1:43, Crist Clark wrote: [snip]
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?
I lock the door. But it's just a regular door, I haven't spent the time and money fitting a bank vault door to the front of the house. That would be silly. If the homograph problem isn't too hard, yeah, fix it. If it is hard, it may not be worth it. From what I know, this isn't easy, but technically, not impossible. However, it seems rather expensive to implement to me, since it requires buy-in from lots of independent groups, and if one group decides not to play, it really screws up the whole works. If that's what we're arguing about, where the cost-benefit line lies, reasonable people can disagree.
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.
Good advice. Always weigh the risks. This message might not really be from Iljtch van Beijnum, but how would I really know the difference anyway? This mail here might not be from my mom, but why would someone impersonate her to send me some fake stories about their trip to Maine? Maybe that link in the mail isn't really to their snap shots from the trip... but they sure did find an actor that looks an awful lot like my dad. This other mail might not really be from my manager. If he asks me to kill the circuit to our alternate site, I might lean over and ask him or give him a call about it. This other email says I won a lottery in Amsterdam that I've neve heard of. Somehow, I'm not buying that one at all. If someone calls me and claims to be my new account representative at my bank, I'd probably believe her and listen to her sales pitch, but if she were to start asking a lot of questions that she should already know the answers to, I'd get suspicious.
(Law enforcement at your door? How do I know those badges are real?)
Are guns drawn? They, whoever they are, gonna bust the door down if I don't open it? Do I have a choice? Are they asking questions that I would answer if this was just anyone at the door whether it was someone claiming to be a reporter, a private detective, or just curious neighbor? Is anything about them making you uncomfortable? Do feel free to call up the police station (non-emergency though, please) to check up on them. Some do advise people, especially women travelling alone, not pull over for what appear to be police vehicles in secluded areas, but to have them follow to someplace with other people around. Not sure I would give that advise. For similar reasons, some police departments have policies whereby unmarked police cars never make routine traffic stops at night. But I would definately advise someone who feels vulnerable to not let in someone like a utililty employee who shows up unannounced at their house even if they produce an ID badge without calling the utility to check up on them (and don't get the number from the person at the door).
Never give out your password to ANYONE, EVER.
Always sound advice. Unless you watch _Seinfeld_ and have a bank that violates fire codes. Then you know when you may need to give it away to save a life, "Bosco! Bosco!" -- Crist J. Clark crist.clark@globalstar.com Globalstar Communications (408) 933-4387
Crist Clark wrote:
If the homograph problem isn't too hard, yeah, fix it. If it is hard, it may not be worth it. From what I know, this isn't easy, but technically, not impossible.
Yes. It's _really_ not difficult to fix, particularly for domains which also enforce a single-script-per-label rule and apply bundling using a homograph table, or support only a single language character set.
However, it seems rather expensive to implement to me, since it requires buy-in from lots of independent groups, and if one group decides not to play, it really screws up the whole works.
And this is what is nice about the Moz/Opera fix: it scales on a per-registry basis, so that registries who don't buy in get their IDN's appearing as Punycode in about 10-15% of web browsers (and rising!), possibly more if other browser vendors adopt the same solution, creating commercial pressure on them from their customers. And users of those browsers still don't get spoofed by the non-cooperators: they will just see Punycode. In many cases, a registrar can solve the problem by putting a few words on their site describing their existing policy, and sending a single E-mail. In more general cases, something like the following should be quite effective: * Add a single extra DB field to their internal database * Add about 100 lines of code to their registration interface, the guts of which are on the lines of: if contains_mixed_scripts(new_label): return reject_application("labels may only have letters from a single script") if sql_lookup("SELECT * FROM REG_TABLE WHERE NORM_LABEL = %s AND PARENT_DOMAIN = %s", homograph_normalize(new_label, parent_domain)): return reject_application("this label looks too similar to an existing label in the same parent domain") # Otherwise... really_register_new_label(parent_domain, label, homograph_normalize(new_label), other_data) return accept_application("your label has been registered") -- Neil
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
On 18-jul-2005, at 22:49, Brad Knowles wrote:
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.
Iljitsch van Beijnum wrote:
On 18-jul-2005, at 22:49, Brad Knowles 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
At 11:55 PM +0200 2005-07-18, Iljitsch van Beijnum wrote:
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. -- Brad Knowles, <brad@stop.mail-abuse.org> "Those who would give up essential Liberty, to purchase a little temporary Safety, deserve neither Liberty nor Safety." -- Benjamin Franklin (1706-1790), reply of the Pennsylvania Assembly to the Governor, November 11, 1755 SAGE member since 1995. See <http://www.sage.org/> for more info.
On Mon, 18 Jul 2005 23:55:08 +0200, Iljitsch van Beijnum said:
On 18-jul-2005, at 22:49, Brad Knowles wrote:
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.....
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
At 9:40 PM -1000 2005-07-18, Randy Bush wrote:
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..... -- Brad Knowles, <brad@stop.mail-abuse.org> "Those who would give up essential Liberty, to purchase a little temporary Safety, deserve neither Liberty nor Safety." -- Benjamin Franklin (1706-1790), reply of the Pennsylvania Assembly to the Governor, November 11, 1755 SAGE member since 1995. See <http://www.sage.org/> for more info.
participants (8)
-
Brad Knowles -
Brandon Butterworth -
Crist Clark -
Iljitsch van Beijnum -
John Levine -
Neil Harris -
Randy Bush -
Valdis.Kletnieks＠vt.edu