Analytics
5/10/2012
04:04 PM
Connect Directly
Google+
Twitter
RSS
E-Mail
50%
50%

New .secure Internet Domain On Tap

'Safe neighborhood' top-level domain will require SSL, DNSSEC, and other security measures for websites

A new top-level domain (TLD) in the works for the Internet will bake security in from the outset: The .secure domain will require fully encrypted HTTPS sessions and a comprehensive vetting process for websites and their operators. If the new domain takes off, it could shift the way Web domains are secured.

It's basically a "safe neighborhood" on the Net, its creators say, and is one of the first next-generation TLDs to emerge from the new Internet Corporation for Assigned Names and Numbers (ICANN) program that opens up the TLDs beyond the 21 existing global domains that include .com, .org, .net, and .edu. Artemis Internet Inc., a wholly owned subsidiary of NCC Group plc, has applied with ICANN for the new .secure domain in the competition for thousands of new TLDs aimed at better classifying companies and people by industry, interest, or location.

"'Effortless security' is our tagline," says Alex Stamos, CTO at Artemis. "Right now, when you go to .com, you have to look for five different visual clues to figure out 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."

Stamos 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. You can create a namespace where you can do more secure things, so if you are a bank that runs hundreds of websites and have some website for users who do billion-dollar transactions," that site could go to the .secure domain, he says.

The .secure domain, which still must be approved by ICANN, will verify domain applicants' identities and continue to authenticate them if they acquire a domain. It requires mandatory DNSSEC-signing of every zone, the use of TLS (SSL) for all Web sessions, and DKIM and TLS for SMTP email. Artemis also will enforce its acceptable use and security control policies, and randomly scan subdomains for adherence to those policies, as well as for any malicious content, such as malware or phishing.

Stamos says verification will include a vetted physical address and a signed paper contract, as well as two-factor authentication. "No shenanigans are allowed ... no cybersquatting, phishing, or using words like 'bank' that sound legitimate" but are being abused by non-banks, for example, he says. "Every application will be approved or rejected by a full-time employee of our company."

Why a security-named domain? "We saw the Internet was in a period of malleability: DNSSEC is being deployed, IPv6 transition is [under way], and in the middle of all of that, this TLD [program] is happening. The Internet is now wet concrete again and we want to make a positive impact," Stamos says. "We wanted to take that opportunity to create new namespaces where old rules don't apply. You have to opt in and agree to [our] rules if you want to join."

[ Half of IT security experts either don't know what DNSSEC is or don't understand it very well. See DNSSEC Finally Comes To .com, But Secure DNS Still Has A Long Way To Go. ]

But critics say there shouldn't be a need for a separate, more secure domain space. Ideally, all sites would be secure. "In principle, the safe neighborhood idea is not without merit, but I would like to see it implemented with any domain name. With that and a commitment from browser vendors to support a special secure mode of operation, it just might work," says Ivan Ristic, director of engineering for Qualys. Ristic says it would require a large amount of collaboration among the affected parties because the Web ecosystem "is so diverse."

And there are a few big obstacles with establishing this new, more secure TLD, Ristic says, starting with existing branding. "The main problems I see is that companies have a significant branding investment in their existing domain names, and that they will not want to move elsewhere without good reason," he says. The best reason to go there would be "perceived security" for their customers, but even that is a tricky proposition, according to Ristic.

"But are people really going to understand what .secure provides assuming, for a moment, it does provide security? For example, we have EV [extended validation SSL] certificates right now, and people/consumers generally don't care," Ristic says.

And .secure will only be able to control so much about a website's security. "It does solve one problem: some bastard on a WiFi hotspot trying to man-in-the-middle your SSL connection. But it doesn't make a bank site more secure. It doesn't stop SQL injection," says Robert Graham, CEO of Errata Security.

Qualys' Ristic echoed the same concerns. "If there's a XSS problem, .secure sites are going to be equally vulnerable," he says.

Errata Security's Graham says the real driver of the new secure TLD will be the browser vendors. If Firefox and Chrome, for example, were to get on board, it would fly, he says. "This would be one step toward tying the SSL key to the DNS key. What everyone wants is for SSL to be based on the DNSSEC key," Graham says.

Meanwhile, Artemis is working with other as-yet unnamed Internet companies under the auspices of the Domain Policy Working Group, which is creating a Domain Policy Framework specification that spells out how browsers and mail servers would implement .secure's security functions, for instance. The final spec will be submitted to the Internet Engineering Task Force (IETF).

Stamos expects ICANN to sign off on .secure, and for the new TLD to be up and running June or July 2013. "We are building something for 50 years [out]. My goal is for my grandchildren and great-grandchildren to be using .secure domains," he says. The initial target customers will be financial institutions, social media sites, technology companies, and healthcare organizations, he says.

Have a comment on this story? Please click "Add Your Comment" below. If you'd like to contact Dark Reading's editors directly, send us a message.

Kelly Jackson Higgins is Senior Editor at DarkReading.com. She is an award-winning veteran technology and business journalist with more than two decades of experience in reporting and editing for various publications, including Network Computing, Secure Enterprise Magazine, ... View Full Bio

Comment  | 
Print  | 
More Insights
Comments
Newest First  |  Oldest First  |  Threaded View
Securbob
50%
50%
Securbob,
User Rank: Apprentice
5/12/2012 | 8:03:30 PM
re: New .secure Internet Domain On Tap
-What type of 2FA would be implemented? I've noticed many of the global cloud providers moving to the use of a telephone (mobile or other) as a form of a token where the user is asked to telesign into their account. Definitely think this is the way of the future!
Steeltemplar
50%
50%
Steeltemplar,
User Rank: Apprentice
5/11/2012 | 2:50:04 PM
re: New .secure Internet Domain On Tap
I think this is a good concept as long as it is well-managed.
Register for Dark Reading Newsletters
White Papers
Flash Poll
Current Issue
Cartoon
Video
Slideshows
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2014-2963
Published: 2014-07-10
Multiple cross-site scripting (XSS) vulnerabilities in group/control_panel/manage in Liferay Portal 6.1.2 CE GA3, 6.1.X EE, and 6.2.X EE allow remote attackers to inject arbitrary web script or HTML via the (1) _2_firstName, (2) _2_lastName, or (3) _2_middleName parameter.

CVE-2014-3310
Published: 2014-07-10
The File Transfer feature in WebEx Meetings Client in Cisco WebEx Meetings Server and WebEx Meeting Center does not verify that a requested file was an offered file, which allows remote attackers to read arbitrary files via a modified request, aka Bug IDs CSCup62442 and CSCup58463.

CVE-2014-3311
Published: 2014-07-10
Heap-based buffer overflow in the file-sharing feature in WebEx Meetings Client in Cisco WebEx Meetings Server and WebEx Meeting Center allows remote attackers to execute arbitrary code via crafted data, aka Bug IDs CSCup62463 and CSCup58467.

CVE-2014-3315
Published: 2014-07-10
Cross-site scripting (XSS) vulnerability in viewfilecontents.do in the Dialed Number Analyzer (DNA) component in Cisco Unified Communications Manager allows remote attackers to inject arbitrary web script or HTML via an unspecified parameter, aka Bug ID CSCup76308.

CVE-2014-3316
Published: 2014-07-10
The Multiple Analyzer in the Dialed Number Analyzer (DNA) component in Cisco Unified Communications Manager allows remote authenticated users to bypass intended upload restrictions via a crafted parameter, aka Bug ID CSCup76297.

Best of the Web
Dark Reading Radio
Archived Dark Reading Radio
Marilyn Cohodas and her guests look at the evolving nature of the relationship between CIO and CSO.