dready blog v2.0

Tina Dam and I caught up during ICANN San Juan on the current state of IDN TLD work within ICANN and that was when I first found out that she was putting together a live IDN TLD test bed which includes translations of the string .test into eleven written languages (Arabic, Chinese-simplified, Chinese-traditional, Greek, Hindi, Japanese, Korean, Persian, Russian, Tamil and Yiddish) and ten scripts (Arabic, Cyrillic, Devanagari, Greek, Han, Hangul, Hebrew, Hiragana, Katakana, Tamil).

I was very excited to hear that and wanted to blog about it but there was much to catch up at work so I let it slide.

Two days ago, an update from ICANN on this project:

ICANN today finalized the IDN .test Evaluation Plan and continued taking steps toward insertion of IDN strings in the root zone. Recent changes to the plan are based on comments received on the IDN public forum and also from consultations with ICANN Technical Advisory Committees. This last version was approved by the ICANN Board at their 14 August 2007 meeting. The resolution directs ICANN Staff to implement the IDN .test Evaluation Plan, and report back to the ICANN Board following the conclusion of the evaluation.

Specifically, the Board approved the delegation of eleven evaluative top-level domains representing the term ‘test’ translated into: Arabic, Persian, Chinese (simplified and traditional), Russian, Hindi, Greek, Korean, Yiddish, Japanese and Tamil. Following this ICANN Board approval, the delegation request will now go through standard IANA procedures for insertion of top-level domains into the root zone. The technical evaluations of IDN TLDs and their usability in various applications will proceed following their delegation.

This is a major milestone in the IDN Program Plan and signals a significant step forward towards Internationalization of the DNS. It is currently anticipated that delegation of these TLDs and the evaluations, as described in the plan, will commence in September 2007.

I would like to applaud ICANN (specifically Tina) on bringing the project this far. This is a major undertaking, and an important one too, for the following reasons:

1. It works across the Internet — not just an isolated test that involved a couple of PCs running in a lab environment; they are going to insert these labels into the root zone! This is the only way to involve the most diverse mix of participants in the test bed. The fact that it requires no special setup (like tweaking of hint files) may lower the barrier for entities such as ISP’s, who are traditionally seldom interested in the development of IDN, to participate.
2. As a result, it allows the most diverse array of test cases possible. Just imagine how an innocent domain name gets passed around applications, resolvers, recursive and authoritative DNS servers through a myriad of functions, API calls and networking protocols. It’s supposed to work but who knows for sure?
3. It tests major scripts used by regions with an immediate need for IDN-TLDs (Latin would have induced yawns)

I’m sure there are skeptics and ICANN-haters out there who will dismiss this for time-wasting activity, etc. The truth is, no one has actually tested IDN TLD’s on Internet-wide scale before. And no, country-wide deployments will not suffice because the diversity of software environments and cultures simply isn’t there.

And if you’re a proponent of the Just-do-it school of thought, this should be seen as a move in the right direction. If no major problem was found during the live test, it will shut the mouths of those who are doubtful.

We should take advantage of this test to file bugs for your favourite software vendors and get them to support IDNs! When was the last time IANA inserted a test TLD to the root? Tell them that if IANA agreed to put these test strings in the freakin’ root, this is not a default ignorable technology alright!

So, help spread the word and test the Internationalized Internet!

नमस्ते

The second piece of news following the localization of EchIDNA into Korean is that we have just launched Korean IDN registration in .BIZ three hours ago. I won’t divulge the numbers here but let’s just say that it far exceeded my expectations.

You may be wondering if there is any connection between our Korean launch and the localization of EchIDNA. Aside from yours truly being involved in both projects, it is purely coincidental. We have been preparing for the Korean launch for a few months, and in doing so have consulted with NIDA (National Internet Development Agency in Korea) and have adopted their language table (with 2,350 KS X 1001 Hangeul characters). The table is available here: http://www.neulevel.biz/idn/KR_Table.pdf and will be posted to the IANA Repository of TLD IDN Practices soon.

If you have a .BIZ Korean IDN and would like some free links, submit it to IDNSearch.net!

Ever since I learned about the RegisterFly trouble, I’ve been frantically trying to transfer my domains out of that crook of a registrar.

Some of my domains registered with RegisterFly had Enom as the registrar of record because RegisterFly was an Enom reseller before “getting accredited” themselves. One of them was particularly problematic because the authorization code was not showing in RegisterFly’s control panel and I had to send a bunch of documentations to Enom to get the domain moved to an Enom account. I’ve been twisting my fingers for the past week and am relieved to finally have all my domains transferred to GoDaddy. The only thing I lost out on is some $15 worth of credit in the RegisterFly account, which I am dead sure will not see the light of day.

Now, as long as Bob Parson doesn’t start using the company funds to buy a private jet or some villa in the carribean I reckon I’ll be safe.

Few lessons learnt from this exercise:

• Always keep your whois data up-to-date, particularly the email address
• Renew early (at least 3 months before the expiry)
• Select a reputable registrar - this one is hard as they all suck, just a question of which one sucks less, and a balance between price and reliability.

All my domains are with Registerfly, which is in deep trouble. I won’t re-iterate all the details here because GoDaddy’s Bob Parson has summarized it very well in his post.

So, I’ve been busy trying to transfer my domains to GoDaddy. In case you think I’m some big-time cyber-squatter¹, I have 17 domains in total - hardly any “portfolio”. Keeping my fingers crossed that all my domains including dready.org survives the transfer (it’s tricky because the expiry is near.)

¹ aka “domainer”.

The OpenID phishing issue is a hard one to solve, particularly because it aims to:

1. be user-friendly, i.e. it should pass the mother-in-law test; and
2. work on the web platform without special software or browser plugin

So, why is this suddenly a problem?

Not really, phishing is a perennial problem on the Internet that researchers and developers have been trying to solve for many years now. OpenID just accentuates it because RPs are unregulated. You don’t need any agreement with any OP, essentially anyone can set up a web site and put the OpenID login button. If OpenID takes off, RP sites will grow like ’shrooms and user will get used to the idea that if they see the OpenID logo, they can type their URL to login. This only makes it harder for users to discern the good RPs from the bad ones.

This is really a social problem, and not a fault of the OpenID protocol. Users need only to trust their OP, and not the RPs that they interact with. If a rogue RP sends you to a page the poses as your OP but the URL doesn’t match your OP’s, you bail out. Doesn’t that sound simple? Well, the cold hard fact is that phishing works and there are research¹ to prove that people get tricked very easily.

Numerous ideas to mitigate phishing attacks have been floating around the OpenID list and on the OpenID mini-blogsphere. Ben Laurie argues for a client-side solution:

Authentication on the web is broken, and has been for a long time. The OpenID fanboys want OpenID to work on any old platform using only standard software, and so therefore are doomed to live in the world of broken authentication. This is fine if what you protect with your OpenID is worthless, but it seems clear that these types of protocol are going to be used to authenticate for things of value.

…

This is the root of the problem: if you want to protect anything of value, you have to do better than existing Web solutions. You need better client-side software.

The picture is not so sunny, however, because most users:

• won’t know / bother to install specialized plug-in or upgrade their browsers unless they’re forced to
• won’t know the difference between citibank.com/signon and citibank.com-banking-foobar.com

And even if they installed those anti-phishing toolbars and what not, they still fall for it!

While I can’t decipher the wirings of the mums-and-dads who fall prey for phishing attacks, I know that I get lazy sometimes and just don’t bother. Then I remember this little trick that Firefox introduced to ensure that users get the warning before installing extensions — Introduce a delay in the dialog box before it can be dismissed. That sort of worked for me, at least for that 5 seconds I can’t click so I might as well read a little.

So, here’s an idea for a browser (or plug-in) implementation:

FUNCTION form.onsubmit()
  IF !form.contains-password-field()
    RETURN ok
  END IF

  IF form.action.domain IN trusted-domains
    RETURN ok
  END IF

  SHOW WARNING-DIALOG (delayed-dismissal=5 secs)

  IF continue-button.clicked
    ADD form.action.domain TO trusted-domains
    RETURN ok
  ELSE // cancel-button.clicked
    RETURN not-ok
  END IF
END FUNCTION

The idea is that you should only submit passwords to sites that you have previously added to the trusted-domains list. This idea is not new, and has been proposed by several on the OpenID list.

Where I think could really make a difference is the way in which WARNING-DIALOG is constructed. It should contain the following:

• If the current page and the form target page are on different “effective domain”, emit warning. There are legitimate use cases for this, and we don’t want to overemphasize it, but it should raise suspicion.
• Display the “effective domain” of the form prominently.
• If the form target is not a HTTPS URL, emit warning.
• Warn the user that the target is not known to the browser to be trusted, and that this could be a sign of phishing.
• A continue button that is greyed out for 5 seconds to force the user to read the above information.
• A cancel button that is focused by default so hitting enter will dismiss the dialog and cancel the request.

An “effective domain” as I call it is defined as the DNS name in the URL stripped of insignificant parts. This basically means that we can use Mozilla’s Effective TLD Service that I blogged about earlier to summarize a URL for display to the user so that us.rd.yahoo.com becomes just yahoo.com, and it will correctly work for things like www.netbank.com.au, which returns netbank.com.au instead of com.au.

A sample dialog might look like:

There are a few advantages to this proposal:

• it works on all password forms, not just for OpenID
• it forcefully disrupts the flow of the user and the delay may help the user to be more cautious

The downsides are:

• it only works for password phishing, other information such as credit card numbers will go through without warning
• phisher can replace the password input field with javascript / DHTML / flash to bypass the check

Even with these restrictions, I still think that it brings significant value in terms of mitigating password phishing attacks. This is of course very raw and there is much room for improvement. All comments and suggestions are welcome.

¹ Thanks to Mike Beltzner for the links to these phishing research papers.

UPDATE: Kim Cameron’s latest blog post about Integrating OpenID and CardSpace has some nice pictures of the modal OpenID phishing attack scenario.

This was going to be a “Dear LazyWeb” request, but after some research I found what I wanted.

Recent discussions about security and phishing on the OpenID list got me thinking about the problem space.

DNS plays a critical role in the security of OpenID because

1. URL is the identifier type used
2. User should only trust the OP with which he/she has an account with.

The “Phishing and OpenID” discussions on the OpenID list actually hinges on point #2 above. Ben Laurie wrote about it here. In short, OpenID opens the door for a malicious RP to send a user to a spoofed OP-lookalike and collect his/her password.

Back to DNS. I have, on numerous occasions in the past, tried to look for a list of domains where registrations are open for public. This varies from TLD to TLD, e.g. .biz accepts registration directly on the second level, .us also does but delegates two-letter subdomains to US states, and .uk only accepts registrations on the third level after .co.uk, .ac.uk, etc.

Well, it turns out that the Mozilla folks needed this list in order to disallow web sites setting cookies for the entire .co.uk or similar domains. Currently, they block just the TLDs so example.com cannot set a cookie for .com, but 2nd level onwards domain cookies are allowed. This could easily cause cookies to be stolen by any site rooted in the same domain.

So, this advisory started this bugzilla entry at Mozilla and it eventually led to the creation of this API and this list (see attachment). They call it the “Effective TLD” list, which is really a misnomer because they are not necessary just TLDs. It was decided in the bug discussions that the term “effective TLD” is easier to digest that anything else, though I’d prefer to call it “Security Restricted Domains”. Whatever, as long as it gives me the content I want.

Many will probably criticize Mozilla for creating yet another list that gets stale the moment it is created. Indeed, TLDs get created and 2LDs within TLDs are introduced and deprecated so often that such a list will be hard to maintain. Moreover, many organizations assign names to registrants at a level that doesn’t involve the TLD registry. Examples include CentralNIC’s .<country-code>.com and *.blogspot.com, and countless others. Add to it the introduction of IDN TLD may well be in less than 2 years. Keeping a definitive list is not feasible. Nevertheless, I would argue that depending on your needs, this list could still be very valuable, as is the case with the cookie problem that they are trying to solve.

So, what has this got to do with OpenID? I shall leave that to a different post.

We launched 5 new languages for IDN in .BIZ today. They are Danish (da), Icelandic (is), Norwegian (no), Spanish (es) and Swedish (sv). Prior to this, the only language available in .BIZ was German (de), launched in October 2004.

I’d like to take this opportunity to thank DK-Hostmaster, ISNIC, NORID, NIC-SE and Cary Karp of MuseDoma for their help and advice on these tables. The work on these tables really started 2 years ago when we first had the intention to launch additional languages, so I am very proud and relieved that they made it out!

Here’s a summary of the non-ASCII characters available for registration:

If you’re looking to register a Scandinavian or Spanish domain name, visit your favourite domain registrar to get yourself one.
When you’re done and made a web site out of it, don’t forget to submit it to IDNSearch.NET!

This is a follow-up post about OpenDNS that I wrote about previously. Founder David Ulevitch responded to my concerns, to which I have responded over email and I’d just like to share it here along with some afterthoughts.

These points may not make much sense without reading the previous post so if you might want to first read David’s comments.

1. I have configured some of my boxes to use OpenDNS, and it has been going well. I have not measured the performance but I trust that OpenDNS will do everything in their capacity to keep the service responsive. After all, that is their most basic value proposition!
2. I still maintain that negative caching is essential, even though David attested that it “doesn’t impact [their] nameserver as much as it would impact [their] webserver.” Just to recap, if you turned off the typo-correction feature and query for a non-existent domain, it will return you an NXDOMAIN response with no record. Most recursive DNS servers in this scenario would return you the SOA record for the parent domain. The SOA minimum field value is then used by the resolver for negative caching so that the next time the same domain is asked within a short period of time it doesn’t need to ask the upstream server again. Not only does it reduce the load on OpenDNS, it also saves time on the client the second time the same name needs to be resolved (assuming the resolver understands negative caching.) Why OpenDNS is not doing it is beyond me.
3. David disagrees with my view that shifting DNS resolution responsibility from the ISPs to OpenDNS is a big problem. His point is that the reliability and feature set of OpenDNS will make the service attractive to companies that wishes to outsource recursive DNS to a third party. That’s fine, but I’m talking about home users who use OpenDNS servers and call up their ISP whenever something is not right. If something were to go wrong between the ISP and OpenDNS’s servers, they will be the only customers experiencing DNS black-out and the ISP call centre will have to take the calls. For example, I’m in Australia and I’m using OpenDNS as my upstream DNS server. If the southern cross cable has a fault (as it happens fairly frequently), I may get very limited connection to the US. In order to verify that only International traffic is affected, I would visit some Australian sites and see that everything is fine. However, because my queries have to go across the Pacific, it would probably not make it through at times like this. This is just an example but links can go down between any two points on the network and most of the time it is out of OpenDNS’ control.
4. I like what OpenDNS is doing and am all for having more control over my Internet access. For the record, I do think that DNSBL’s are necessary but don’t believe it should be a binary switch no matter how many blacklists assert the same information. Some other mechanism is required to make the decision to flip the switch (like SpamAssassin’s hosts of heuristics.)
5. I also pointed out a potential problem area for OpenDNS because ads are served on non-existent domains. For example, the domain “verizon-wireless.com” is not registered as of this writing (and Verizon uses the dashless version verizonwireless.com). Typing that in your browser while using OpenDNS brings you to the OpenDNS’s search page, which has dashless version as the first hit - very good. But the user could also click on other links on that page. Furthermore, I don’t understand why a hidden-frame is used in the search page (if you clicked on any link in the search page, the non-existent domain is still on the URL bar.) I’m not saying there’s anything unethical about that; recognize that some companies are sticky about it, Verizon being one such example (as I’ve witnessed in their dispute with eNom at ICANN Marrakesh.)

On the bright side, I wonder if on-the-fly IDN homograph detection is possible using OpenDNS. It wouldn’t be politically right but nevertheless an interesting use-case.

The usual disclaimer about these ramblings being my personal opinion and not of my employer applies.

I have serious doubts about the new OpenDNS service.

The idea is simple – point your DNS resolver to their name servers. What you get in return is faster cached results and phishing site blocking. They make money by advertising on the pages returned when you make a spelling mistake in the domain name. OpenDNS also claims to have “caches at the major intersections of the Internet” though I have not been able to get to anywhere but their California Verio site (tried tracerouting from Australia, US east coast and west coast.) So, I’m not sure if they are using anycast.

Having done some preliminary technical evaluation of the service, here are my thoughts (feel free to disprove me):

(more…)