Yet again, we are hearing calls for the creation of a new Top Level Domain (TLD) using enhanced security and safety as the rationale. We've seen pushes for these kinds of new TLDs before. .xxx was proposed as a restricted TLD for voluntary use by adult-oriented web sites. Those registering domains under .xxx would be required to abide by certain contractual terms surrounding customer privacy, child protection, unsolicited commercial email, etc. While this sounds all well and good on the surface, what would be the business case from the perspective of a successfully adult-oriented site? From what I can tell, there are only negatives to an adult site moving under .xxx. For one, it is now a no-brainer to block access to your site (and all the others under .xxx). In addition, by registering under .xxx TLD, you've just agreed to a slew of new contractual terms, governing everything from communications with your customers, site access controls, use of meta-tagging, mandated privacy policies, etc. Short of top-down governmental coercion, few if any successful adult-oriented sites would be likely to move under the .xxx TLD.
Conversely, .kids was proposed as a restricted TLD for use by sites hosting family and child-friendly content. The argument seemed to be that .kids would represent a kind of child-safe walled garden on the Internet. No need for those pesky content filters, just let the rug rats loose on .kids and all will be well. The arguments against the creation of .kids tended to focus on free speech concerns and the fear that this TLD could evolve into a kind of segregated Internet which would be legally foisted on minors. A .kids TLD might also create just the kind of target rich environment that child predators would be drawn to. Further discussion of the pros and cons of the .kids proposal are not really of concern here.
Our friends at F-Secure are advocating the creation of a .bank TLD as a way to combat phishing and online financial fraud. Whatever organization is entrusted by ICANN with management of the new TLD would restrict domain registrations to banks and other reliable financial institutions. Go read the proposals. Their argument seems to be that the creation and use of a .bank TLD will tend to decrease the level of phishing and online financial fraud.
Putting aside the practical difficulties of determining who and what represents a registered financial institution, there are a number of problems with this proposal. Mikko Hypp'nen, Chief Research Officer at F-Secure, notes that "Right now, customers have no good way of automatically being able to tell whether or not a bank website belongs to the bank." While I agree with Mikko on this sad state of affairs, I fail to see how a new .bank TLD would demonstratively improve the situation.
When it comes to phishing, confusion is the key to success. A new TLD will simply add to the confusion. Regardless, the phishers don't currently see any need to use the same TLDs as the banks anyway. Their phishing URL simply has to look "close enough" for at least one person to be fooled.
For example, an attacker using the Rock Phish kit might use links that look something like:
hxxp://secureaccess.example.com6278928login.7host.hk/login.do
hxxp://secureaccess.example.com.134492.login.7host.hk/login.do
hxxp://secureaccess.example.com%2Elogin.7host.hk/login.do
These kinds of URLS are proven to fool enough people to turn a profit despite the fact they are not using the same TLDs. Creating a new .bank TLD will be confusing to many people, who might fall for URLs such as:
hxxp://secureaccess.example.bank6278928login.7host.hk/login.do
hxxp://secureaccess.example.bank.134492.login.7host.hk/login.do
hxxp://secureaccess.example.bank%2Elogin.7host.hk/login.do
These would typically be caught by the latest browsers' anti-phishing functionality, however many people have not, cannot, or will not upgrade. To defeat these, expect attacks using text in image attachments (imagine the image displaying the password in the latest Storm Worm / Peacomm Trojan runs). An image may display text such as:
Login to www.example.bank now!
but hyperlink to:
hxxp://secureaccess.example.bank%2Elogin.7host.hk/login.do
If a .bank TLD is created, I'd predict wide spread phishing attacks using announcements of new .bank sites from the financial institutions. In fact, financial institutions would be adding to the confusion if they announce their move to the .bank TLD via email to their customers. It will be difficult to distinguish the legitimate announcements from the phishing attempts. Other attempts at confusing the user would involve the use of JavaScript or browser exploits that set or obscure status bars and hyperlink mouse-overs to display a .bank TLD.
Besides the potential for increased confusion and social engineering, I have some technical reservations with using registration under a TLD as a basis for trust. From a technical perspective, the domain name (or in this case TLD fragment) of a website really tells you nothing about that domain's identity or trustworthiness. A domain name really just exists as shorthand for an IP address and is typically resolved through DNS. Putting aside arguments over DNSSEC, DNS is a fundamentally untrustworthy system. Don't get me wrong here, DNS works great and is incredibly useful, but it simply wasn't designed with security as a requirement.
DNS lookups are susceptible to a variety of attacks (cache poisoning, MITM, spoofing, etc.), and just like any other TLD, .bank would be just another part of the globally distributed DNS system. From a technical perspective, the results from a .bank address lookup would be no more trustworthy than those from looking up a .com address.
The trust a user places in their online session with the Bank of Example has little to do with the domain registrar that sold Bank of Example their "secureaccess.example.com" domain. It matters little to the user whether Bank of Example choose Network Solutions or Go Daddy as their domain registrar, or whether the site is registered under the .com or .net TLDs. Trust in the site's "identity" really springs from its possession of a valid signed X.509 server certificate issued to "secureaccess.example.com", and transitively, from the policies and procedures of the issuing Certificate Authority. Short of validating an X.509 server certificate provided by the site, the site's domain name is really just an untrustworthy assertion.
One can view the .bank TLD proposal and others like it as attempts to 'harden' the domain name registration system by raising the financial and bureaucratic bar to entry and by making contractually explicit what is expected of the party registering a domain. A more fruitful approach might involve hardening the organizational linkage between a site and its purported 'identity': the Certificate Authorities and their policies and procedures. That leads us into a discussion of VeriSign's new extended validation certificates and IE7's support for the visual indication of extended validation. And that, folks, is for a future blog post.
Conversely, .kids was proposed as a restricted TLD for use by sites hosting family and child-friendly content. The argument seemed to be that .kids would represent a kind of child-safe walled garden on the Internet. No need for those pesky content filters, just let the rug rats loose on .kids and all will be well. The arguments against the creation of .kids tended to focus on free speech concerns and the fear that this TLD could evolve into a kind of segregated Internet which would be legally foisted on minors. A .kids TLD might also create just the kind of target rich environment that child predators would be drawn to. Further discussion of the pros and cons of the .kids proposal are not really of concern here.
Our friends at F-Secure are advocating the creation of a .bank TLD as a way to combat phishing and online financial fraud. Whatever organization is entrusted by ICANN with management of the new TLD would restrict domain registrations to banks and other reliable financial institutions. Go read the proposals. Their argument seems to be that the creation and use of a .bank TLD will tend to decrease the level of phishing and online financial fraud.
Putting aside the practical difficulties of determining who and what represents a registered financial institution, there are a number of problems with this proposal. Mikko Hypp'nen, Chief Research Officer at F-Secure, notes that "Right now, customers have no good way of automatically being able to tell whether or not a bank website belongs to the bank." While I agree with Mikko on this sad state of affairs, I fail to see how a new .bank TLD would demonstratively improve the situation.
When it comes to phishing, confusion is the key to success. A new TLD will simply add to the confusion. Regardless, the phishers don't currently see any need to use the same TLDs as the banks anyway. Their phishing URL simply has to look "close enough" for at least one person to be fooled.
For example, an attacker using the Rock Phish kit might use links that look something like:
hxxp://secureaccess.example.com6278928login.7host.hk/login.do
hxxp://secureaccess.example.com.134492.login.7host.hk/login.do
hxxp://secureaccess.example.com%2Elogin.7host.hk/login.do
These kinds of URLS are proven to fool enough people to turn a profit despite the fact they are not using the same TLDs. Creating a new .bank TLD will be confusing to many people, who might fall for URLs such as:
hxxp://secureaccess.example.bank6278928login.7host.hk/login.do
hxxp://secureaccess.example.bank.134492.login.7host.hk/login.do
hxxp://secureaccess.example.bank%2Elogin.7host.hk/login.do
These would typically be caught by the latest browsers' anti-phishing functionality, however many people have not, cannot, or will not upgrade. To defeat these, expect attacks using text in image attachments (imagine the image displaying the password in the latest Storm Worm / Peacomm Trojan runs). An image may display text such as:
Login to www.example.bank now!
but hyperlink to:
hxxp://secureaccess.example.bank%2Elogin.7host.hk/login.do
If a .bank TLD is created, I'd predict wide spread phishing attacks using announcements of new .bank sites from the financial institutions. In fact, financial institutions would be adding to the confusion if they announce their move to the .bank TLD via email to their customers. It will be difficult to distinguish the legitimate announcements from the phishing attempts. Other attempts at confusing the user would involve the use of JavaScript or browser exploits that set or obscure status bars and hyperlink mouse-overs to display a .bank TLD.
Besides the potential for increased confusion and social engineering, I have some technical reservations with using registration under a TLD as a basis for trust. From a technical perspective, the domain name (or in this case TLD fragment) of a website really tells you nothing about that domain's identity or trustworthiness. A domain name really just exists as shorthand for an IP address and is typically resolved through DNS. Putting aside arguments over DNSSEC, DNS is a fundamentally untrustworthy system. Don't get me wrong here, DNS works great and is incredibly useful, but it simply wasn't designed with security as a requirement.
DNS lookups are susceptible to a variety of attacks (cache poisoning, MITM, spoofing, etc.), and just like any other TLD, .bank would be just another part of the globally distributed DNS system. From a technical perspective, the results from a .bank address lookup would be no more trustworthy than those from looking up a .com address.
The trust a user places in their online session with the Bank of Example has little to do with the domain registrar that sold Bank of Example their "secureaccess.example.com" domain. It matters little to the user whether Bank of Example choose Network Solutions or Go Daddy as their domain registrar, or whether the site is registered under the .com or .net TLDs. Trust in the site's "identity" really springs from its possession of a valid signed X.509 server certificate issued to "secureaccess.example.com", and transitively, from the policies and procedures of the issuing Certificate Authority. Short of validating an X.509 server certificate provided by the site, the site's domain name is really just an untrustworthy assertion.
One can view the .bank TLD proposal and others like it as attempts to 'harden' the domain name registration system by raising the financial and bureaucratic bar to entry and by making contractually explicit what is expected of the party registering a domain. A more fruitful approach might involve hardening the organizational linkage between a site and its purported 'identity': the Certificate Authorities and their policies and procedures. That leads us into a discussion of VeriSign's new extended validation certificates and IE7's support for the visual indication of extended validation. And that, folks, is for a future blog post.