.Secure FAQ

I have received many excellent questions and concerns since we announced our effort to build the .Secure top-level-domain.  This page will serve as a single repository for my answers and I will update it as the idea continues to evolve and new questions come in.  If you would like to ask a question and see the answer here, please send it to alex at artemis dot N-E-T or @alexstamos.

Why do you think .Secure will make things better?

.Secure will provide verified identity of registrants, require the use of otherwise optional best-of-breed technologies, enforce security rules through continuous checking and secure the end-to-end experience via the Domain Policy Framework under development at the Domain Policy Working Group. For more information you can read my series of posts starting here.

What will a .Secure domain cost?

We are still working on pricing in collaboration with our initial customers.  Clearly, a domain that includes human verification, phone support, continual scanning and the deployment of innovative new technologies will cost significantly more than $12.99/year. Even at a much higher cost, we expect the price of buying the domain to be a small fraction of the security budget spent to protect the types of applications that would most benefit from being hosted under .Secure.

We do, however, recognize that there are many types of applications that might be interested in .Secure, and we plan on offering reduced-cost options to Non-Profits, NGOs and individuals. Reduced-cost domains registered by individuals will be subject to strict limits on how they can present themselves to end-users and prohibited from processing transactions on those domains.

Which registrars will sell .Secure domains?

This is an area under consideration. Clearly the benefits we want to bring to .Secure require a much closer relationship between registrants and the registry than the incumbent gTLDs, so we are planning on operating the registry and a registrar using the “Vertical Integration” model. The guidelines around VI are in constant flux and we look forward to participating in the discussion at ICANN Prague and beyond.

We are also interested in discussions with brand-management companies and other registrars that believe they would be able to support our unique needs. If you represent such a registrar feel free to contact us.

Won’t .Secure just attract hackers looking to make a point?

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.

.Secure is not a domain for everyone; we are targeting organizations who intend to provide the safest, most trustworthy Internet experience possible. While we intend to have lower-cost tiers of the product for non-profits and individuals, these customers will be held to the same standards as our Enterprise customers and will need to provide the same quality of secure experience.

Whatever increase in adversity needs to be weighed against the benefits provided by the upgrades domain owners will need to make to join .Secure. Even many of the most security-sensitive global brands are not yet using excellent security technologies (such as Content Security Policy) and the on-boarding process to .Secure will lead to many useful improvements to existing web applications. We will also catch bugs or configuration errors with our scanning regime that could otherwise have persisted under a .com domain.

Doesn’t a .Secure domain create a false sense of security?

Security is a process, not a destination, and we will need to be clear that we are looking to improve the horrible level of trust on the Internet but are not so arrogant as to think that we can solve all problems for all users all at once.

No one can promise perfection. What we are promising is that Artemis and the .Secure domain holders are engaged in a continuous process of testing, improvement and if necessary, vigorous response. This is certainly more than you will get from .com or any other announced gTLD.

What happens the first time a .Secure domain is hacked?

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.

Part of the .Secure security policy will be an agreement on security SLA. This will cover a number of different scenarios, such as time-to-fix on a bug we find with scanning, a bug found externally but reported responsibly, and a bug under active exploitation. At any given moment our greatest concern is the protection of .Secure’s end-users, and our policies and the services we provide domain registrants will reflect that.

I am sure there will be interest from the white-hat research community in claiming the first bug in a .Secure domain, and I am open to suggestions on how we could productively harness that energy. An example would be a bug-bounty program among volunteer .Secure domains, permitting testing against non-production instances of .Secure applications without harming end-users or running afoul of the law. Any other ideas are appreciated.

What happens the first time a .Secure site is caught hosting malware?

Our security SLA will provide an appropriate amount of flexibility to domain holders who are actively working to close a bug. Our anti-malware policy will be much less flexible. A legitimate domain owner with a good track record will be required to immediately remove any malware from their site and mitigate whatever issues allowed it to be posted in the first place, whether that be a server vulnerability, XSS bug or silly business model like “upload whatever binary you want to this page”.  Sites that are suspected of intentionally posting malware will lose DNS resolution immediately and will need to prove to our satisfaction that any malicious actions were inadvertent and will be prevented in the future.

What do you think you can find using scanning of .Secure sub-domains? Won’t you miss bugs?

Our scanning regime has four purposes:

  1. Enforcement of our security and acceptable use policies.  Acceptable use includes scanning for malware.  Security policy checks include looking for insecure includes, improper TLS install, DNSSEC signed zone, etc…
  2. Early discovery of DPF compatibility issues.  The Domain Policy Framework is intended to communicate the security settings of a domain via DNS to a browser before an initial connection. A mismatch between a domain’s DPF setting and server configuration could cause compatibility issues and unnecessary warnings to users, so we would like to detect those problems early and not rely on user reports.
  3. Discovery of network vulnerabilities.  We intend to scan for common issues found in operating systems and network services. We will have the ability to perform these scans when most necessary; for example, if a critical OpenSSL flaw is discovered we will be able to quickly initiate a targeted scan for that issue among .Secure domains and notify vulnerable customers.
  4. Discovery of pre-auth web vulnerabilities.  Any major website continuously faces automated attempts to find flaws such as SQL Injection or XSS. We intend to scan the pre-authenticated portions of web applications for a variety of issues that lend themselves well to non-human testing methods.
It is true that our scanning will not find every possible flaw, and we will still strongly recommend human-powered penetration testing of all of an app’s functionality. We do, however, believe that we will be able to catch an impactful number of flaws early in their lifecycle. These scan results will also serve as a useful proxy for deeper or more complicated bugs; a site with XSS in it’s front search box likely has some more serious issues.

What about scanner false positives?

Our ticketing interface where domain registrants see and respond to issues will include the ability to report a potential false positive. No actions will be taken without human investigation and approval, so there is no need to worry about a single false positive taking a domain down.

Will every .Secure customer need to pay Artemis for scanning services?

Scanning performed in service of our compliance program will be included in the base price of a .Secure domain. Additional scans will likely be available for purchase a-la-carte.

Can’t other companies do the same thing, perhaps under .supersecure?

We are actually more intimidated by the potential of .gigasecure and .thesesitesaresuperawesomesecure.

In all seriousness, we hope that our move to establish a more trustworthy and secure TLD inspires others to follow. We established the Domain Policy Working Group with this goal in mind; any existing or new gTLD is welcome to participate in our development of DPF, and Artemis is happy to offer services to other gTLDs whom intend to make their corners of the Internet more trustworthy.

What keeps Artemis from lowering the standards of .Secure to make more money?

This is a reasonable concern and one that we take seriously. I should note that the intended structure of DPF, with a base policy burned into browser builds, makes it difficult to ever lower our standards.

There should also be economic reasons for not lowering our standards. Although I do not feel completely comfortable with the “gated neighborhood” metaphor used in the press to describe .Secure I do think there is at least one useful parallel. Artemis is in some ways like a Home-Owners Association (HOA); we create rules that keep the neighborhood safe, and people decide to move in the the neighborhood due to those rules. Like any HOA we will be beholden to our membership, and it will be important for us to create the proper incentives to insure that existing .Secure domains put pressure on the “HOA” to keep the standards that made the TLD desirable in the first place.

Admit it, Artemis will never raise the standards for .Secure.

This is not true, and one of the main goals of DPF was to create a method to upgrade our security standards without requiring all domains to make changes at once. Although we are still working out the details, here is one scenario for performing a TLD-wide upgrade:

  1. A researcher demonstrates a compelling need for requiring a new version of a critical security protocol.
  2. Artemis publishes a draft of the next version of our security rules, say .Secure Security Policy v2.2.
  3. Artemis collects feedback from existing customers on the difficulty of upgrading and necessary timeline.
  4. Artemis publishes the new policy, which goes into effect immediately for all new .Secure registrants.  The baseline DPF rule for these applicants are updated and downgrade is disallowed.  Artemis announces a deadline for upgrades by existing customers, say six months.  This timeline would be based upon the severity of the issue and the difficulty of mitigation.
  5. Artemis begins scanning for non-compliance with the new policy, and alerts are sent to domain administrators containing detailed instructions on how to come into compliance.
  6. As existing domains upgrade their systems to come into compliance, the alerts on their .Secure web interface are cleared and they are prompted to update their DPF record.
  7. At the announced date, the DPF record for all registrants is updated with the new version and administrators are notified that they are likely to face compatibility problems with DPF-enabled browsers.
  8. Artemis registers the base policy change with the DPWG, which then publishes the new base .Secure policy alongside the policies of other gTLDs for integration in upcoming browser releases.

What happens when a user sees site.com redirect to site.secure?

The creation and use of new gTLDs by existing brands will have a large impact on brand management, marketing, SEO and advertising. We do not have official recommendations at this time, but I assume the best practice for brands adopting .Secure and other new gTLDs will be to aggressively market the new name, visually notify the user of the change in-band to the web page and to provide an explanation of why they decided to use a new gTLD.

This is also a reason for our recommended extension of HSTS to cover gTLD redirects, so that the .com->.ngTLD occurs automatically while users become aware of the new address.

Can my controversial organization/company get a .Secure domain?

Our policies are designed to promote user trust and safety and are intended to be content neutral, so I generally do not believe they will pose a problem as long as your organization promises to follow them. We do, however, reserve ourselves a broad latitude to prevent fraud, manipulation or dishonest business practices, so don’t expect to operate an affiliate scheme or give away “free iPads!!!” from a .Secure domain.

6 responses

  1. Pingback: Answering Questions about .Secure « Unhandled Exception

  2. Pingback: My own private Internet: .secure TLD floated as bad-guy-free zone | Ars Technica

  3. Pingback: {Quick Post} Some thoughts on .secure « Cатсн²² (in)sесuяitу / ChrisJohnRiley

  4. Pingback: Tyinternety.cz | Nové doménové koncovky se blíží. S čím počítat a jak se připravit

  5. >Can my controversial organization/company get a .Secure domain?
    >Our policies are designed to promote user trust and safety and are intended to be content neutral, so I generally do not believe they will pose a problem as long as your organization promises to follow them

    You generally don’t believe it’ll pose a problem? I find a hard time believing something like nambla.secure, or stormfront.secure, or even a hypothetical how-to-wage-jihad-while-raping-children-and-being-homophobic-btw-this-is-purely-informational.secure would be approved, even though those sites are legal (albeit quite controversial). I would not be surprised if sites like that applied, and were given the rediculous “while we generally don’t disapprove of controversial sites, we have to draw a line somewhere” treatment. What I want to know is whether this .secure tld will be completely and utterly amoral (amoral != immoral) and will accept all sites that conform to the .secure security policies and aren’t dishonest, fraudulant, etc.

  6. Might be worth looking at the ImperialViolet post from the 6th July 2014… Adam Langley (who works on Google Chome) is asking for one or more of the new TLD’s to have HSTS enabled for all sub-domains.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s