Answering Questions about .Secure

The initial tech press coverage of Artemis and .Secure has been very gratifying, although it creates a situation where many people are raising the same questions or concerns. Instead of trying to respond to everybody in 160 characters I have created a living FAQ page to accumulate questions and answers.  Let me know if there is a question you would like me to add.

Posted from Peet’s Coffee, San Carlos, California

Introducing something that might become the Domain Policy Framework

I have already started to lay out why we are going after the .secure TLD, let’s start the discussion of how it would be different.

As I have repeated to a dozen reporters in the last 36 hours, there are three legs to the .secure tripod, Verify, Secure and Enforce.  Although we are able to mandate the security controls and protocols be put in place by servers under .secure with today’s technology, we do not have the ability to communicate this escalated level of protection to the browser.  Doing so is a critical component of providing the effortless end-to-end secure experience that I believe users deserve.

To that end we are working on chartering the Domain Policy Working Group.  We cannot announce the initial slate of members while legal work is still occurring, but I do appreciate the support that others have voiced for the project.

I have attached our very very very early draft below.  This document was meant to explore the opportunities provided to us by a protocol like DPF, and there is a lot of work to be done before it is ready for the IETF.  In the meantime, feel free to leave comments here to send them to alex at  If you are really inspired to help, then let us know at info at and we’ll let you know when membership slots open.

Please keep in mind that this protocol is meant to be usable on any TLD, and in fact part of Artemis’ business will be to host DPF and other security services on behalf of security-sensitive TLDs.  This protocol should also be usable by the incumbent TLDs, so it’s important to design something that can scale to .com size while not negatively affecting sites that do not opt-in to DPF services.

Posted from the now freezing sidewalk outside Cafe Nero, Waterloo Bridge, London

Why .Secure? Part I: Listening to the User

“Security and usability must not be in conflict. If it’s not safe, it’s not usable; if it’s not usable, it can’t be used safely.”
            – Chris Palmer, circa 2008

If you are one of the dozens of people who have found this blog you undoubtedly have heard of our controversial conversation-starting proposal to operate the .secure TLD.  I thought I would take this opportunity to discuss our motivations for going after this part of the namespace before diving into more technical details.

The Internet experience is completely broken for the vast majority of the world.  Of all of the problems that could lead one to this conclusion (I18N, governance, the inability to leave behind 1970’s technology) I would like to focus on an area somewhat within my expertise: trust and safety.  As you read this, on this planet someone is using a laptop on a café wifi network to pay a bill, over there that person is clicking on a link from an SMS message, and a lot of people are sending private information in an email.

If you interrupted any of these people and asked verbally if they trusted the Internet, or more specifically the technology they held in their hand that moment, they would likely hear the leading tone in your voice and answer “No.”  Yet apparently they each believe that the likelihood of a negative outcome is so low that there is no need to think before performing these actions.  Why do they think that?  In the developed world I would guess this “trust” derives from the trust we have been trained to put into all technology.  Do you carefully read a status message and push the correct button to keep your car from exploding?  Do you have to perform a risk assessment each time you cross a bridge?  No, you do not, because the engineers behind these types of products understand risk management under real world use and a great deal of thought is put into fool-proofing them against even a first decile consumer.

Should we blame them that they expect the same from us, the software and security engineers who build the shiny things they love?  When a normal, intelligent educated person picks up a $400 device with the computing power of Apollo-era NASA they naturally assume that somebody has taken care of problems like “click on the wrong link and my phone turns into a spam sending zombie”.  Sure, they read about malware, and hackers, and account take-over… “Heck, Aunt Julie had her identity stolen last year, and nobody figured out how.” I think it’s clear that even the most aware consumer still assumes that there is a man behind the curtain.

Which brings us to our topic, misplaced trust in the web.  This is a dialog that perhaps hundreds of thousands of people see each day:


Safari Certificate Error


Imagine that your uncle calls you, asking which button it is safe to push.  Where do you start the conversation?  An introduction to discrete mathematics?  A treatise on the difficulty of factoring large numbers across a finite field? An introduction to the X.509v3 standard?

I have deep sympathy for the browser engineers who maintain this code; they have been given the impossible job of creating a user experience that warns a user without bothering them and that allows a user to accept a risk they almost certainly do not understand.  We have come a long way from the completely obtuse dialogs of the past, but I doubt the average user is more likely to make the correct choice than they did with IE4.

One of the key goals of .secure is to invert the user’s security experience.  The human does not exist to serve the software.  Why does the user politely ask “I would like to go to my bank” and then need to interpret the 21st century pixelated entrails to determine if they arrived at their destination safely?  The user is in charge; they tell the software what they want, and it’s our jobs to make the software listen.



In my view, .secure is not a category, it is an expression of intent.  When a user types, they are not saying “I want to go to the bank in the category of secure”, they are saying “I want to go to my bank securely”.  That means that all of the software standing between them and their destination needs to understand this intent, and then make the thousands of small decisions needed to make it so.   .Secure and the Domain Policy Framework are not the only ways to make that happen, but I believe they are the most expedient.

Posted from the sidewalk in front of Cafe Nero (cafes close at 8!?!), Waterloo Bridge, London