Re: Non-English Domain Names Likely Delayed
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
Re: Non-English Domain Names Likely Delayed
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
Re: Non-English Domain Names Likely Delayed
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.999% 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, [EMAIL PROTECTED] 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.
Re: Non-English Domain Names Likely Delayed
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, [EMAIL PROTECTED] 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.
Re: Non-English Domain Names Likely Delayed
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.
Re: Non-English Domain Names Likely Delayed
Unfortunately, the problem is inherent in human writing systems. Consider rnicrosoft.com and paypaI.com. And people are no better than muppets in ensuring they don't screw themselves up The good news is that fairly simple homograph rules can be applied Rules aren't safe, it involves humans. I presume that if a Chinese bank were to register their name then the similar .com would be blocked for them (just as the Chinese paypal alike would be blocked). What if the .com is a blogger, would the Chinese bank accept being blocked, would they exert pressure to have theirs anyway or would the blogger be fair game for lawyers/ICANN managed domain hijacking? If it's too hard people won't understand it brandon
Re: Non-English Domain Names Likely Delayed
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, [EMAIL PROTECTED] 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.
Re: Non-English Domain Names Likely Delayed
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.)
Re: lo0kal1ke domains, Non-English Domain Names Likely Delayed
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
Re: Non-English Domain Names Likely Delayed
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 ** **
Re: Non-English Domain Names Likely Delayed
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 [EMAIL PROTECTED] Globalstar Communications(408) 933-4387
Re: Non-English Domain Names Likely Delayed
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 [EMAIL PROTECTED] Globalstar Communications(408) 933-4387
Re: Non-English Domain Names Likely Delayed
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
Re: Non-English Domain Names Likely Delayed
On Sun, Jul 17, 2005 at 04:29:52PM +, Fergie (Paul Ferguson) [EMAIL PROTECTED] wrote a message of 49 lines which said: Forwarded Message from Neil Harris [EMAIL PROTECTED] --- ... After extensive analysis and discussion, the Mozilla community and Opera have already produced a fix for this, Which is highly questionable and that is rejected by most european ccTLDs. 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. The Polish registry already refused to comply, saying that the Mozilla foundation has no legitimacy deciding the registration rules in .pl.
Re: Non-English Domain Names Likely Delayed
On Sun, Jul 17, 2005 at 09:49:32PM -0700, Dave Crocker [EMAIL PROTECTED] wrote a message of 25 lines which said: 2. Who is the authority that decides whether a TLD uses an acceptable policy? That's the big problem with this so-called solution.
Re: Non-English Domain Names Likely Delayed
Stephane Bortzmeyer [EMAIL PROTECTED] writes: 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. The Polish registry already refused to comply, saying that the Mozilla foundation has no legitimacy deciding the registration rules in .pl. And it's completely their right to do this, however, if they are at all subject to pressure from their constituency this policy will probably change over time if this scheme becomes a de-facto standard (say, for instance, M$ and Apple decide to run the same whitelist, the discussion is effectively over). What's the drawback again to letting commercial forces help shape the discussion here? I forget... ---Rob
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
Re: Non-English Domain Names Likely Delayed
Stephane Bortzmeyer wrote: Forwarded Message from Neil Harris [EMAIL PROTECTED] --- ... After extensive analysis and discussion, the Mozilla community and Opera have already produced a fix for this, Which is highly questionable and that is rejected by most european ccTLDs. 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. The Polish registry already refused to comply, saying that the Mozilla foundation has no legitimacy deciding the registration rules in .pl. Stephane, can I ask you what your detailed objections are to the Moz/Opera mechanism, and could you let me know your proposal for an alternative mechanism for preventing IDN spoofing? I completely understand the need for registries to define and control their own rules, since every registry has different needs. Thus, I agree with you that the Mozilla foundation does not have, and should not have, any right whatsoever to decide registries' registration rules. However, by the same principle, Mozilla, Opera and other software vendors also have the right to choose their policy for how they display domain names in their products' GUI. Ultimately, the decision of what policy is used devolves to the user, who decides what software they want to install on their machine. The Moz/Opera anti-spoofing mechanism is the result of widespread public analysis and discussion, and has the following advantages: * it deals with the actual problem: the visual representation of characters to the user -- the problem is, quite literally, in the eye of the beholder * it is simple to code and deploy: about ten lines of code for the Mozilla implementation. * it is based on simple and non-political principles * it requires only a minimal amount of data to be distributed with the software * it is the sole survivor of a large number of alternative proposals that were considered and rejected. Unlike most of the other rejected proposals, it does not need any modifications to the DNS protocol, or distribution of language codes for labels, nor does it require multiple DNS lookups, large character tables in the browser, or real-time access to WHOIS information. (I can tell you in great detail about some of the flawed alternative proposals, if you like). * it is based on a much more thorough analysis of the problem than the earlier ICANN proposals, and builds on the experience of the Unicode community, and the earlier analysis of the spoofing problem for the CJK languages performed for RFC 3743. For example, simple script restrictıons alone, as per ICANN, do not solve the problem -- there are plenty of subtle homographs in the Latin alphabet, such as the one embedded in this sentence. * it does not treat IDNs as second-class citizens * it is language- and script-agnostic * it is scalable on a per-registry basis, so there's no need for a flag day, and requires no action on behalf of the registry beyond that which might be expected as a service to their customers, who have a reasonable expectation that their domains not be easily spoofed. * and, most of all, it uses human, and not technical, means to provide a chain of trust from the registry to the application to the user I must say that, from a user's perspective, I find it hard to understand why any registry would not want to put their anti-spoofing policy -- assuming they have one -- on public display, thus encouraging software vendors to regard their IDN labels as safe to display within their software. In the long run, of course, it makes sense for best common registry anti-spoofing practices to be codified, probably in an RFC, or through the Unicode consortium. However, until then, the maintenance of an ad-hoc list by software vendors seems to be a powerful incentive in the short term for registries to implement and publish anti-spoofing policies which encourage trust. There are a vast number of possible policies which registries could introduce, any of which might serve this purpose. For example, for .fr, it could be as simple as saying something like labels in .fr must consist only of characters from the set -, 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, a, b, c, d, e, f, g, h, i, j, k, l, m, n, o, p, q, r, s, t, u, v, w, x, y, z, à, â, æ, ç, è, é, ê, ë, î, ï, ô, ù, û, ü, ÿ, œ, putting that statement on their website, and letting the software makers know about it. For .pl, which appears to want to support multiple character sets including the Cyrillic alphabet, it could be to say we implement the character set restrictions of draft-bartosiewicz-idn-pltld-06.txt, together with blocking bundling using the confusables.txt table as per UTR #36-3. In my opinion, either of these statements would persuade me that the
Re: Non-English Domain Names Likely Delayed
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)
Re: Non-English Domain Names Likely Delayed
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 ATT service over on 1-800-OPER-ATOR. Why do you think ATT 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, [EMAIL PROTECTED] 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.
Re: Non-English Domain Names Likely Delayed
Dave Crocker wrote: After extensive analysis and discussion, the Mozilla community and Opera have already produced a fix for this, based on only displaying Unicode IDN labels where the registry publishes and enforces well-defined anti-homograph policies, and displaying the Punycode equivalent ...snip... 3. How does this apply to subordinate domains that might or might not enforce acceptable policies, given that no all policy-making is at the TLD level? It assumes that organization-level delegation of names is enforced by the TLD registry for all domains that it issues domains in. The assumption is made that operators and users of websites and other services have to place their trust in the chain of organizations delegating the DNS for their domain, and in particular, the one that registered the domain with the TLD registry. This reflects common practice, in which most services involving any significant value or risk are generally operated from their own domains in order to reduce the number of third parties to be trusted as far as possible. -- Neil
Re: Non-English Domain Names Likely Delayed
Stephane, can I ask you what your detailed objections are to the Moz/Opera mechanism, and could you let me know your proposal for an alternative mechanism for preventing IDN spoofing? I would suggest that an alternative mechanism should include a set of code points to be used for the on-the-wire DNS protocol and the registry databases. This set of codepoints will greatly restrict the possibility of ambiguity. Right now it is utterly impossible to represent the ambiguity of IBM, ibm, IBM or IbM in the DNS because the set of codepoints only allows for one code to be shared by I and i. This principle could be extended to other scripts so that, for instance, codes for the 2nd and 4th letters of the Cyrillic alphabet could be added while not adding codes for the 1st and 3rd letters because A and B are already there. Two additional items needed are translation tables. One translation table would be the PREFERRED mapping from the DNS codepoints to Unicode. I say preferred because while some people will be happy to see the b as in ibm, others may prefer to see it as B especially Cyrillic users who use B for a completely different letter most of the time. Also, Arabs may prefer to map first and last letters of a domain to the initial and final forms of the letter and use medials for the rest because it looks better most of the time. This does not create exploitable ambiguity. The second item is a comprehensive mapping for all of UNICODE that maps each code point into one of the DNS code points. This should be defined as an algorithm because that allows for a combination of mapping tables and more efficient ways of defining and executing the mapping. It may be painful to upgrade the DNS, but if we are going to do so, we need to try to make it a solution that will work for a long time, not just quick fix patches. I have nothing against the Mozilla solution as a quick fix but I hope that it is used to demonstrate the need for upgrading DNS and fixing the problem at its root. For example, simple script restrictıons alone, as per ICANN, do not solve the problem -- there are plenty of subtle homographs in the Latin alphabet, such as the one embedded in this sentence. Personally, I consider that to be the Turkish alphabet, not the Latin one. Turkic speakers who use Cyrillic also have a habit of adopting munged up characters in their alphabets. I think this is solved by defining the PREFERRED mapping as described above. Turkey would implement it keeping the distinction between the i with and without the dot. Many other countries would opt for sticking in some code like ? to indicate that there is a wierd character there. If I localize my computer to allow Turkish text entry and Turkish fonts, no doubt I would also get the Turkish domain name mapping preferences. And no doubt, central asian countries speaking Turkic languages but using the Cyrillic alphabet would map all the codes into their familiar Cyrillic forms. This is possible because the reverse mapping allows one to type in many different possible UNICODE character forms of a domain name in order to get the same single unambiguous registered domain name. * it is scalable on a per-registry basis, so there's no need for a flag day, and requires no action on behalf of the registry beyond that which might be expected as a service to their customers, who have a reasonable expectation that their domains not be easily spoofed. I think if we are going to upgrade the DNS, then registries will have to adapt in the same way as everybody else. And if that includes a flag day, then so be it. I suspect, however, that we will find some less disruptive way to transition, perhaps with two flag days to indicate the beginning and the end of a transition period. For example, for .fr, it could be as simple as saying something like labels in .fr must consist only of characters from the set -, 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, a, b, c, d, e, f, g, h, i, j, k, l, m, n, o, p, q, r, s, t, u, v, w, x, y, z, à, â, æ, ç, è, é, ê, ë, î, ï, ô, ù, û, ü, ÿ, œ, putting that statement on their website, and letting the software makers know about it. And if a Turkish cultural centre in Paris wants to register a domain name with the undotted i, then what? National boundaries have no relationship to cultural boundaries. Admittedly, in my solution suggested above, if such a turkish domain name did exist, anyone who did not have a localized system supporting entry of the undotted i would not be able to enter the name of the domain. They could still access the website by leveraging a website that allowed them to access it by clicking a link, in the same way that http://www.translit.ru provides a Cyrillic keyboard for computers without Cyrillic localization installed. --Michael Dillon
Re: Non-English Domain Names Likely Delayed
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.
Re: Non-English Domain Names Likely Delayed
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, [EMAIL PROTECTED] 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.
Re: Non-English Domain Names Likely Delayed
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 [EMAIL PROTECTED] Globalstar Communications(408) 933-4387
Re: Non-English Domain Names Likely Delayed
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.
Re: Non-English Domain Names Likely Delayed
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
RE: Non-English Domain Names Likely Delayed
I don't know of any other IEEE/NANOG/IETF/ICANN-sanctioned method to completely confuse even a savvy IT user who is trying to determine the validity of an SSL site. 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. Sure, there are bugs and hacks. The existence of such does not justify approving new measures (in this case, a glaring security hole) as a global standard. In fact, quite the opposite: folks are generally trying to fix such problems, not push them forward in public policy agenda. It's clear that no one intended for the side effect of a complete meltdown in the user layer of SSL (where the only thing you can do is double-check the URL in your browser and verify there's a padlock icon in your status bar), but the side effect is there and it's naive to pretend that fairness to non-English folks or globalization justifies a hole this large. Certainly, the vulnerability is just as much a problem for the targeted benefactors of this change. -Jason -- Jason Sloderbeck Positive Networks jason @ positivenetworks . net -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Crist Clark Sent: Monday, July 18, 2005 4:43 PM Cc: NANOG Subject: Re: Non-English Domain Names Likely Delayed 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. 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 [EMAIL PROTECTED] Globalstar Communications(408) 933-4387
Re: Non-English Domain Names Likely Delayed
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 [EMAIL PROTECTED] Globalstar Communications(408) 933-4387
Re: Non-English Domain Names Likely Delayed
On 18 Jul 2005, at 18:43, Jason Sloderbeck wrote: I don't know of any other IEEE/NANOG/IETF/ICANN-sanctioned method to completely confuse even a savvy IT user who is trying to determine the validity of an SSL site. If I was feeling especially cynical (and hey, who isn't on a Monday?) I'd say that the validity of an SSL site is a lot harder to judge than people think, and a savvy IT user would do well to trust very few of them. For a well-known common name with a global reputation, you might have a reasonable expectation that a successful wander down a certificate chain might be worth trusting: a CA would have to be fairly remiss to issue a certificate to some random customer who claimed to be Amazon or Microsoft (or Amäzon or Micrøsoft, for that matter). However, when it comes to a web store whose name isn't well-known, good certificate frequently means little more than the operator of the site is able to mark up some letterhead and send a fax. And of course, nobody here would be guilty of clicking accept on a warning that the validity of a self-signed certificate cannot be determined. Thought not. Maybe a bit of healthy distrust is overdue for injection into the CA economy. Joe
Re: Non-English Domain Names Likely Delayed
Forwarded Message from Neil Harris [EMAIL PROTECTED] --- Fergie (Paul Ferguson) wrote: ...sez Vint...due to the prevalence of phishing: http://www.msnbc.msn.com/id/8586332/ - ferg Paul, I'm not registered as a poster on the Nanog list, so I thought I'd let you know that this problem is already well under control. After extensive analysis and discussion, the Mozilla community and Opera have already produced a fix for this, based on only displaying Unicode IDN labels where the registry publishes and enforces well-defined anti-homograph policies, and displaying the Punycode equivalent otherwise. All that is needed is a couple of lines of code in the Punycode - Unicode translation code in the application, and a whitelist of TLDs. See http://www.mozilla.org/projects/security/tld-idn-policy-list.html for more details. This delegates the responsibility of catching homographs to the registries, rather than trying to catch them using ad-hoc heuristics at the browser end. In many cases, this can be as simple as restricting labels within a TLD to use a small set of non-confusable characters. In others, with wider character sets, techniques such as bundling and blocking sets of confusable labels using homograph tables can be used. RFC 3743 is a case in point. For an excellent summary of the technical details, which is intended to help anyone attempting to eliminate homographs from a naming system, see the latest, much-expanded, version of Unicode TR #36, which also links to machine-readable confusables tables. http://www.unicode.org/reports/tr36/ 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. You might want to summarize to the list. -- Neil
Re: Non-English Domain Names Likely Delayed
After extensive analysis and discussion, the Mozilla community and Opera have already produced a fix for this, based on only displaying Unicode IDN labels where the registry publishes and enforces well-defined anti-homograph policies, and displaying the Punycode equivalent 1. It's strange that so many months of discussion and debate about this elsewhere missed such an obvious and complete solution. 2. Who is the authority that decides whether a TLD uses an acceptable policy? 3. How does this apply to subordinate domains that might or might not enforce acceptable policies, given that no all policy-making is at the TLD level? d/ Dave Crocker Brandenburg InternetWorking +1.408.246.8253 dcrocker a t ... WE'VE MOVED to: www.bbiw.net
Re: Non-English Domain Names Likely Delayed
Sorry to be like this on a nice saturday morning, but... What exactly are people who are too stupid to know the difference between a LANGUAGE and a SCRIPT doing here? I say we patent the latin script and refuse to license it to the US.
Non-English Domain Names Likely Delayed
...sez Vint...due to the prevalence of phishing: http://www.msnbc.msn.com/id/8586332/ - ferg -- Fergie, a.k.a. Paul Ferguson Engineering Architecture for the Internet [EMAIL PROTECTED] or [EMAIL PROTECTED] ferg's tech blog: http://fergdawg.blogspot.com/
