The '.secure' domain would enforce rigorous security
Connecting state and local government leaders
Artemis Internet promises to enforce high standards for organizations in the new domain, and to kick out anyone who slacks on security.
A start-up Internet registry has applied for the ambitiously named .secure top-level domain, which organizers say would enforce high security standards for organizations operating in that name space.
Those operating subdomains within .secure would be individually vetted, required to abide by acceptable use and security control policies, and subject to disconnection, said Alex Stamos, chief technology officer of Artemis Internet Inc.
“If you are not in compliance, we will turn your site off until you fix it,” Stamos said.
Related coverage:
ICANN to reopen applications for new top-level domains
Agencies way behind in using DNSSEC to secure .gov domains
At the same time Artemis announced its bid for a new generic TLD, it also announced an industry effort to develop technical and policy standards that would enable enforcement of minimum security controls for websites at the browser level.
The Domain Policy Framework would be a language for expressing security preferences of a TLD and its subdomains. This would be distributed via the Domain Name System at the same time the address is looked up, allowing browsers to verify that a requested site meets the security requirements of the domain before connecting.
Artemis is a San Francisco-based subsidiary of U.K.-based NCC Group. It applied to the Internet Corporation for Assigned Names and Numbers for the .secure domain name under ICANN’s New Generic TLD program, which is expected to expand the gTLD space from the current 22 domains to a thousand or more. There had been 2,091 applications for new gTLDs submitted before the application process was temporarily shut down by a security glitch in April. It is expected to reopen for a final week starting May 22.
ICANN will publish a complete list of domain names that have been applied for after the application period has closed.
TLDs are the suffixes on URLs that denote the community in which an online site is operating. The .com TLD — the largest — is for commercial operations, .edu for educational, and .gov for government sites. Each domain is run by a registry that operates the infrastructure allowing names and addresses to be looked up on the Domain Name System.
The first delegations of new TLDs originally was expected to begin in January 2013, but that probably will be pushed back some by the problems in the application system.
Assuming the new domain is approved, “we’re using summer 2013 as our target for operating,” Stamos said.
Stamos said .secure would not allow domain squatting — registering someone else’s brand name as a subdomain name — or the use of typos, misspellings or other deceptive names. “If we feel it is going to confuse users, we won’t allow it.” It also will not allow any subdomain to be used for malicious or illegal purposes, such as hosting malware or sending spam.
Policing these requirements will not come cheap, and the cost of registering a name in .secure would be higher than in other TLDs, Stamos said, although prices have not yet been set. That means .secure will not be for everyone.
“We are not looking to be as big as .com,” he said. “Not everyone will fit in .secure. Our goal is to build a small but very trustworthy domain,” with customers numbered in the thousands of rather than millions.
Stamos said interest from organizations with sensitive online operations, such as financial institutions, has been positive. He said it is likely such organizations would continue to maintain public sites in the .com space while moving some high-security operations, such as financial transactions, to .secure.
He said .secure plans to use the Domain Policy Framework that is to be developed by the Domain Policy Working Group, but the framework could be used in any domain.
DPF would not be a security technology itself but a protocol to better enable the use of existing technologies, such as HTTP Secure. Despite development of secure protocols for the Web, they are underused because they are optional and browsers connecting to a site do not know what to expect or demand in the way of security.
Using DPF to publish minimum security requirements for a domain and its subdomains would allow end users, through their browsers, to refuse connections to sites that do not live up to their published policies.