A ".secure" top-level domain [LWN.net]

By Nathan Willis
May 16, 2012

On May 10, Ars Technica reported on a new proposal to create a .secure top-level domain (TLD) that would enforce deployment of encryption and security protocols on all sites and scrutinize all registrants to verify their identity. The idea is being floated by the company that wants to be the registrar and manager of the TLD, however, and regardless of how noble its intentions may be, it still needs to make a strong case for how a domain-bound solution improves on existing security practices.

The initial proposal and initial reactions

The proposal comes from Alex Stamos of research firm iSec Partners, and would appoint Artemis Internet as the gatekeeper of .secure. Artemis would require registered domains to encrypt all web and email traffic (except for HTTP redirects funneling connections towards the appropriate TLS-encrypted site), use DNSSEC, and deploy DomainKeys Identified Mail (DKIM) for spam prevention. In addition, Artemis would employ a rigorous screening process to verify registrants' identities (including reviewing articles of incorporation and human interviews), and routinely conduct security scans of registered sites. The venture has $9.6 million (US) in funding provided by Artemis' parent company NCC Group, a UK-based IT security firm.

The Artemis site says ".secure is not a category or destination. It is an expression of the user's intent to use the Internet safely," but so far offers few additional implementation details. After a number of Ars Technica readers expressed their skepticism in the comment thread, though, Stamos responded to several questions on the site (although, ironically, we have no way to verify that the poster is Stamos).

Several commenters expressed doubt that the lofty goal of enforcing strong encryption and strictly-verified identities was practical on a large scale, while others argued that the proposed rules for registrants offer nothing that secure sites cannot already do today — thus making the special domain unnecessary. To the latter charge, Stamos replied that the goal was to automatically make secure choices whenever the user entered a .secure URL, rather than rely on the user to verify the security of a connection upon visiting a site:

The basic goal of .Secure is to invert the security user experience when using the Internet. Right now you type somesite.com, and then you are expected to look for user interface clues and even dive into details (depending on your expected adversary) to determine whether you got there safely. And if things go slightly wrong, you are prompted to make a decision based upon your understanding of discrete mathematics and the X.509v3 spec.

A reader who goes by VideoGameTech argued that even with a strict security policy enforced on the actual .secure sites, users would still be vulnerable to attacks like DNS hijacking and URL-obfuscation through email spam. Stamos responded that requiring DNSSEC would protect users against DNS hijacking, and that other measures would make spam attacks less likely, saying:

We continue to recommend that legitimate emails like this do not contain clickable links, and that mail/spam providers continue to improve their detection of URL/text mismatch. That being said, we'll be attacking the spam problem in the From: field aggressively with required DKIM and SMTP TLS with a real certificate.

Policy

Stamos also added that Artemis was drafting a proposal called the Domain Policy Framework (DPF), which would allow a domain to specify a security policy to be stored in DNS TXT records that browsers and other client applications could securely retrieve over DNSSEC. He later posted an initial specification of DPF to his blog. The specification itself is hosted at Scribd.com; a PDF version can be downloaded from the Scribd page.

The proposed DPF specification enumerates 15 separate security entries, broken up into "network and identity," "email," and "WWW" sections. They cover basic requirements like whether a domain requires DNSSEC and/or TLS, plus details like expected email signature algorithms, plus general identity information. Artemis has also started a project it calls the Domain Policy Working Group to create DPF, although at the moment it does not list any other members. The group's site does state that its intention is to submit DPF to the Internet Engineering Task Force (IETF) RFC process, and to create supporting standards.

Yet another CA?

Some commenters at Ars Technica and on our own story felt that the proposal boiled down to little more than Artemis vowing to be a certificate authority (CA) that actually acted responsibly — which so many CAs seem to have trouble doing. It would also appear that the .secure domain would require that only the Artemis CA be allowed to sign site certificates for the TLD or else a subverted CA could start issuing bogus .secure certificates. That, of course, means that subverting Artemis itself could lead to the same problem On the other hand, it is at least true that running an entire TLD securely would be more visible to the end user than would running a flawless CA.

Consider, for comparison's sake, the Extended Validation (EV) SSL certificate concept. EV certificates were supposed to bolster security by inflicting a rigorous, fraud-proof identity verification process on all applicants. The trouble was that, as the Wall Street Journal reported, most users failed to notice the difference in their browser's UI. Barring any other improvements, if Artemis managed to cultivate a good reputation for running .secure, it would be easier for a casual user to spot the TLD than to dig into the the certificate chain-of-trust for another site.

Speaking of previous enhanced-security efforts, the .secure TLD was floated as an idea in 2011 as well, under greatly differing circumstances. Back then it was the US government proposing a heavily-fortified subset of the Internet to live in .secure. That proposal had different components, including ongoing monitoring with intrusion detection and prevention software. But Chris Palmer of the Electronic Frontier Foundation (EFF) responded by critiquing the core notion that better identity verification would provide a security for users:

But what does “authentication” mean on the internet? People often (implicitly) take it to mean something like “Through this web browser I am talking to the true Wells Fargo Bank, and Wells knows that I am the true Chris Palmer.” However, when one computer presents credentials (such as a username and password pair or a cryptographic certificate) to another, the link between software data structure and real-world entity (like a person or a business) is weak. It is no stronger than the person’s or business’ ability to ensure that the computers on both ends are operating correctly and are not compromised, and that the channel between them is secure against network threats. From painful experience we know that our operating systems suffer from numerous design and implementation flaws, and that malware and system hacks are all-too-prevalent. [...] For economic reasons (such as Metcalfe’s Law and economies of scale), networks tend to converge, not diverge. (We will probably use the same computers (and wires!) to connect to the real internet as to the .secure internet.)

Echoing that sentiment, Ars Technica reader Mark Havel asked whether Artemis' .secure proposal would come with any guarantees that security patches would be quickly and routinely applied to all servers on .secure sites. Others pointed out that for end users, the only difference between a .secure site and a site in another TLD would be if Artemis offered liability protection against attacks. As reader Fuzzmz said, "Yes, I can visit a .secure domain with a bit more peace of mind, but if something goes haywire then I'm left in the same place as I was if it happened on a .com domain."

There is also the question of whether a hardened .secure domain would attract a larger share of attackers than would the same sites hosted at .com or other TLDs. Some commenters suggested that cracking a .secure site would be an attractive achievement for fame-seekers. On a separate note, if the .secure TLD did successfully become associated with higher security in end users' minds, it would consequently make a more appealing target.

In short, there is not much in the .secure proposal from Artemis that a server could not implement today (DPF, which is not limited to .secure, necessarily, depends on browser adoption). But even with a secure connection to a fully-patched server, it is up to the human being in front of the screen to pick out all manner of security attacks, from phishing spam to URL obfuscation, and that human being still relies heavily on the browser to expose and communicate threats in an understandable manner. Without question, the principles that the Artemis site hails as critical — verification, security, and enforcement — are vital to creating a secure web and email environment. But the company still needs to make a stronger case for how tying those principles to a particular TLD improves things over the status quo for the human/browser combination, not to mention why that responsibility should rest with a private, commercial enterprise.

(Log in to post comments)