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.
WSJ: Information Security Where the Dangers Are
Both Steve Bellovin and Craig Labovitz show up in today's technology section of the Wall Street Journal. Information Security Where the Dangers Are By DAVID BANK and RIVA RICHMOND Staff Reporters of THE WALL STREET JOURNAL July 18, 2005; Page R1 In the world of cybercrime, the bad guys are getting smarter -- and more ambitious. In recent months, hackers have carried out a flurry of increasingly sophisticated attacks, highlighting the vulnerability of key computer networks around the world.
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: IPv6 push doesn't have much pull in U.S
:) True, but, there's actually another angle to consider. If there is pressure to adopt IPv6 rapidly in a given region, and that given region also happens to drive broadband technology evolution, and North America ends up being dependent on cheap equipment primarily driven by overseas standards.. It is conceivable that North America will have a substantial economic argument for adopting IPv6 on the trailing edge, maybe just past the leading edge if you have additional factors playing into the decision. Or one may just be oblivious to the emergence of IPv6 like it has been to up to this point, and sustain that without any harm whatsoever. The key questions are When will who you want to talk to speak IPv6? When will we have a need (and be willing to pay for) addressing every device individually and directly without intermediary? When will we have a need (and be willing to pay for) pervasive crypto identity? Each person/carrier/user/whatever will answer these differently, and it has a lot to do with how you work, who you do business with, and what economic pressures may apply, and whether or not you can cope with an intermediary or non-native setup. There is no globally correct answer. Or that's at least my view. Flame away. Thanks, Christian -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Iljitsch van Beijnum Sent: Saturday, July 16, 2005 5:33 AM To: Fergie (Paul Ferguson) Cc: nanog@merit.edu Subject: Re: IPv6 push doesn't have much pull in U.S On 16-jul-2005, at 1:57, Fergie (Paul Ferguson) wrote: Someone's been listening: Listening to what, exactly? Still nonsense about address space distribution. And I'm sure Sprint and Verio (MCI/Worldcom/UUNET too? I have a tunnel from them in the Netherlands, not sure what they do in the US) are happy to hear that they're not major U.S. service provider[s] since none of those offers IPv6, right? Also, I mostly disagree with their conclusion: Currently only a handful of U.S. technologists need to worry about IPv6--those that work in the federal government, carriers, researchers and networking vendors. If you're not in one of those categories, the IPv6 bug won't reach you for years to come. Software vendors need to look at IPv6. The OS and router vendors have their stuff in place. The networks will follow when the time is right, but none of it means anything if applications can't work over IPv6. I'm not saying everyone has to love IPv6, but please get those pesky facts straight... * The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential, proprietary, and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from all computers. 162
Re: IPv6 push doesn't have much pull in U.S
On 18-jul-2005, at 18:31, Kuhtz, Christian wrote: If there is pressure to adopt IPv6 rapidly in a given region, and that given region also happens to drive broadband technology evolution, and North America ends up being dependent on cheap equipment primarily driven by overseas standards.. I don't see this. For instance, the need for non-ASCII characters in (for instance) Asian languages has pushed Unicode. Modern systems in NA are all capable of using Unicode. But do users in NA actually _use_ Unicode? ASCII works fine for them 99% of the time. Same thing with IPv6. Windows and MacOS have had IPv6 on board for years. Doesn't mean people use it. The key questions are When will who you want to talk to speak IPv6? That's a key question when you've made up your mind to be one of the last to adopt IPv6. The real key question is: when will it start to make sense to use IPv6 for my own stuff, regardless of what the rest of the world does? In an enterprise environment the ease of never again having to think about how many hosts are going to end up in the same subnet alone may be quite compelling. But it only makes sense when you can turn off IPv4 in most of the network and proxy or translate communications to the outside.
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.
Can someone from AOL contact me offlist?
RE: IPv6 push doesn't have much pull in U.S
On 18-jul-2005, at 18:31, Kuhtz, Christian wrote: If there is pressure to adopt IPv6 rapidly in a given region, and that given region also happens to drive broadband technology evolution, and North America ends up being dependent on cheap equipment primarily driven by overseas standards.. I don't see this. For instance, the need for non-ASCII characters in (for instance) Asian languages has pushed Unicode. Modern systems in NA are all capable of using Unicode. But do users in NA actually _use_ Unicode? ASCII works fine for them 99% of the time. I don't disagree with that point at all. But what I was trying to say goes a little further and is basically the notion that you're likely to use gear that happens to speak Unicode because of other developments and while you may be fine using ASCII most of the time (given that it is a charset specifically developed to meet North American English needs some time ago), you may be receiving a parasitic benefit of it showing up elsewhere or everywhere else. It won't influence purchase decisions perhaps, you won't buy gear X because it doesn't do Unicode, but it may just show up as the defacto standard. Just like other charsets have made it into just about every current, modern operating system and application.. So, you'd adopt just because it's there and it's no worth fighting the current of being different. (GSM in North America is a similar example, I think :-) There are economic forces at work, that have very little to do with the suitability of technology for a specific locale, which may drive adoption of technology. Same thing with IPv6. Windows and MacOS have had IPv6 on board for years. Doesn't mean people use it. Yup. That is absolutely correct. But, if there are huge amounts of actions in a given market place, that's bound to spill over into a different market place because of global distribution of goods. Not because the other, different market asked for it, but just because it's more economical to make one set of gear that is a superset in the end. The key questions are When will who you want to talk to speak IPv6? That's a key question when you've made up your mind to be one of the last to adopt IPv6. Yes, and in terms of volume, that's where I see North America being right now.. We're on a track to be dead last (well, almost) on the path we are on right now (and have been for some years). The real key question is: when will it start to make sense to use IPv6 for my own stuff, regardless of what the rest of the world does? Not if you are fine with what you have, and believe in never change a running system because one doesn't believe it's prudent to keep up with technology... In an enterprise environment the ease of never again having to think about how many hosts are going to end up in the same subnet alone may be quite compelling. But it only makes sense when you can turn off IPv4 in most of the network and proxy or translate communications to the outside. Well, I'm not sure I would be so bold as to say it's an either or choice, but it would have to be for substantial islands of a corporation or other type of organization to make economic sense. Just like there's still antiquated computing gear ( software on it) hopping around happily all over the place, although isolated and put into a scenario where there are gateways or dain bramage impact on the rest of the world is otherwise limited, there will be IPv4 in islands long after IPv6 achieves world domination (which has yet to be seen). If there is a business case for IPv6, it is pandemic rather than epidemic for as far as my rather cloudy crystal ball will let me see... Best regards, Christian The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential, proprietary, and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from all computers. 163
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
clec vs ilec, how do you know who's lying?
Hello everyone, not sure if this is off topic or not since it is will be operational in nature if I can ever get the service set up. :-) I'm having the pleasure, or lack thereof, of ordering some data connectivity via a very large clec which requires the ilec to provide the local loops. Well we're about two months past the estimated install completion and all I get from the clec is continuous blame pointed at the ilec who has now missed three install dates and in turn has wasted staff time sitting there from 8 to 5 each of the days; assuming they were really scheduled in the first place. I know the two types of entities don't particularly like each other but at this point how do I tell who's lying to me? I have supposed work order numbers for the ilec but I don't have any direct contact with them to see if they are real numbers and if the disposition of the previous work orders are what the clec has told me or if they are messing things up themselves and trying to cover it up. Thanks, David
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: Vonage Selects TCS For VoIP E911 Service
At 09:06 PM 7/18/2005, Fergie (Paul Ferguson) wrote: http://www.advancedippipeline.com/166400372 Interesting. No ability to opt-out, and no signup option. So will they use the customer's billing address, attempt to determine location based on IP address or some other voodoo? It'll be interesting to see if they manage to handle vonage boxes that are connected over VPN tunnels that terminate far from where the IP addresses appear to be. Also, Vonage promotes the take your phone service with you idea, so there's a real opportunity for problems. This should be interesting to watch.
