What A Secure Top-Level Domain Can And Can't Do

As Ralph Waldo Emerson once surmised, "Build a better mousetrap and the world will beat a path to your door."

Maybe so. Then again, maybe no.

I have to say I was equally intrigued and amused by the recent news announced by Artemis introducing a new top-level domain (TLD) that folds in security for Internet member sites from inception.

As reported on Decrypted.com, to become a secure "member" in this club you would first submit your organization for screening. In turn, the screening process would confirm you are who you say you are by verifying things like articles of incorporation, trademarks, site address, IP address, and so on. Once you pass this level of screening, you would be supplied with hardware that supports two-factor authentication and registers this at the location for the edge of your network.

Additionally, this membership process would require all data and Web traffic be encrypted end-to-end. Mail traffic would require use of the OTLS (opportunistic transport layer security), which encrypts data before it’s transmitted to the destination server.

For its part, Artemis will continue to scan all the sites with the .secure extension to ensure they are not and have not been compromised in any way. If a compromise is detected (for example, infection by malware), then it is removed from the so-called "walled garden" until it cleaned up. Repeat offenders would be permanently removed.

As reported by Kelly Jackson Higgins here on Dark Reading, Artemis CTO John Stamos believes incremental security, such as a .secure domain, has value.

"Effortless security is our tagline. Right now, when you go to .com, you have to look for five different visual clues to figure what’s going on security-wise," Stamos says. "If you type .secure, you're telling the server or organization that you want to communicate with that you want to be safe and expect them to be as safe as possible. All of that security stuff is taken care of for you."

For his part Stamos doesn't see every .com as a potential customer; instead, he expects financial institutions and other security-sensitive businesses to adopt the new domain for their pages that handle transactions, for example, or sensitive data. "We're not trying to tell people to throw away your .com, but if you are a bank that runs hundreds of websites for users who do billion-dollar transactions, that site could go to the .secure domain," he says.

As you'd expect, this announcement is drawing skepticism from many quarters.

That includes Constantine von Hoffman. In his column on CIO.com, called "Why the New .Secure Domain Idea is a Dud," he draws an inference between personal and corporate responsibility and why neither party in an exchange of data can completely abdicate their respective responsibilities:

"Just as in the physical world, I am responsible for getting myself to the bank securely. I don't run around with money popping out of my pockets, and I don't use random Internet connections to connect to banking sites. That's my responsibility. Just like it's my responsibility to know if I live in a place where my doors need to be locked or I can leave my car keys in the ignition at night. Users should be able to take some parts of online security for granted, but other parts are--and should be--the user's responsibility."

From a technical perspective, there's the complaint voiced by independent researcher Moxie Marlinspike, who concludes that the .secure plan won't solve an underlying problem that arises from putting trust for digital data and services into the hands of commercial entities subject to the whims of various governments, which are notorious for their lax security practices.

"If we sign up to trust the organizations who manage that infrastructure, we're signing up to trust them forever; without any opportunity to change our minds in the future, and without any incentives for them to continue warranting our trust," Marlinspike says.

So where do I come in on this one?

Well, .secure has some good features, and the principles behind its founding appear sound, but it looks, at least from my reading of what has been said so far, that its primary aim is to reduce phishing and hijacking. The measures they suggest (DNSSEC zone signing and TLS for all HTTP) are designed to reassure the end user that:

1) They are communicating with the correct website.

2) Their communications are not being eavesdropped.

These are great precautions against phishing attacks, but what they do not ensure is that the site itself has not been hacked. Some of these measures are things that sites with sensitive information are already doing. In fact, even the most recalcitrant Web security administrators should have learned from FireSheep that sensitive traffic must be encrypted.

The .secure system will apparently scan .secure sites for vulnerabilities and hosted malware with SLAs to fix anything found, but that is not the same as being truly safe.

As Stamos himself says on his Unhandled Exception blog's FAQ, "I'll say it right now: a server running a .Secure site will get hacked. A web app hosted under .Secure will get hacked. Software, like humans, is fallible and we would be foolish to expect or promise perfection with even the best implemented and tested controls."

Moreover (and not being a hacker myself but knowing something about the mindset), I can't help thinking that a .secure domain is the metaphorical equivalent of waving the proverbial red flag in front of a bull’s eyes.

In fact, one of the questions on Stamos' blog asks, "Won't .Secure just attract hackers looking to make a point?" To which Stamos retorts, "Any organization for whom .Secure makes sense is already a target. Their level of adversity currently ranges from small-time criminals and amateurs looking to make a name for themselves up to nation-state actors and dedicated, professional white-hat researchers. It is possible that LocalBookShop Inc. would face additional scrutiny due to a .Secure domain, but attacker quality is not going to differ greatly between payments.globobank.com and payments.globobank.secure."

There's also the sheer marketing effort required to evangelize the .secure domain. In fact, my concern with .secure would be that the average user will not be aware of the subtleties behind it and will assume that .secure means secure. While it certainly raises the bar a little (although only a little because many of the institutions to whom .secure is marketed already take such precautions), it's not the same as a secure gated Internet.

In other words, Artemis has presented a better mousetrap, but the bait it's using to attract members, ultimately, may not be palatable to either the (member) mouse or the (online) company that's trying to trap it.

Brian Royer, a security subject matter expert, Sophos U.S., is partnering with SophosLabs to research and report on the latest trends in malware, Web threats, endpoint and data protection, mobile security, cloud computing and data center virtualization.