>The same way the domain name owner's NS records get into the TLD. By action of the registrar, paid for by the domain name owner. What is the commercial motivation for the registrar to do this? How is this process secured? At what point will specs be available to review? I have been asking these questions of the people that you imagine to have the answers and received nothing but silence. All I hear is people whining in the national press about how the registrars are now the impediment to DNSSEC deployment. >Were you sleeping, or just failed to google "Kaminsky dns"? DNSSEC as currently planned is of zero value against that specific attack. Even if someone was to work out what resolvers and applications should be doing when a signature verification fails, real world DNS will still be vulnerable against the far simpler and more frequent name-jacking attack and the insidious and difficult to defend against BGP layer attack. >Yes, eventually the need for SSL certificates signed by third parties will go away. Those registrars will continue sell such bits, and some folks will even buy those bits. So given the fact that the registrars own the customer interface here, how does ICANN persuade them to do their bidding? Attempts at coercion would bring an anti-trust suit. Essentially what ICANN is saying here is that fifteen years after the Web adopted an open, competitive model for PKI services based on X.509v3, ICANN is now going to replace all that with an as-yet unproven model where it just happens to have total control of the apex zone. There is an important purpose for DNSSEC that only DNSSEC can provide. But that certainly is not replacing a facility that the Web already has with one that provides less security than the weakest form of SSL currently deployed. >But what *specifically* do you see as an increased risk with dnssec that is not already present with ssl certificates? And specifically why won't the mitigation methods for SSL work equally well for dnssec? OK, well first I will point out that I was Principal Scientist for VeriSign (the real one) for 12 years and worked with their people before that. And DNSSEC was on the table then as well. I have seen Crocker and Cerf's previous attempt to deploy this particular model of PKI when we called it PEM. Whole books have been written on how risk and liability are managed in PKI. For example see Ford and Baum 'Secure Electronic Commerce' or the section on PKI in my book 'dotCrime Manifesto' for the condensed version. The model developed by Baum et. al. copied an number of similar models that were in existence and were known quantities to the courts. In particular the notary model and the insurance model. The reason Baum selected X.509 as the certificate format for SSL is that it was the only format at the time that allowed him to annotate the certificate to incorporate the relying party agreement by reference. The relying party agreement in turn consists of three basic sections, the first essentially denies all claims for liability, the second sets up a series of liability caps and the third sets up a scheme of insurance with cover up to the value of the cap. The point here was that at the time SSL was first deployed nobody quite knew who would use it or for what purpose. The biggest risk in litigation was the cost of the litigation itself. So it is better for all concerned to simply offer insurance. DNSSEC has none of these considerations. There is no way to state what the statement means. so even if ICANN comes up with a practices statement there can be no real confidence that a court is going to consider it admissible as being relevant to the proceedings. The bottom line is that should a party suffer some loss and decide to sue, the registrar, registry and ICANN would all find themselves embroiled in the proceedings and nobody can say with confidence what the reaction of the courts will be. Contrast this with the SSL case where the registrar knows that the CA is the sole party on the hook for issuing the cert (unless they agreed otherwise as part of their reseller agreement). As to the likelihood of a loss. Well in the case of SSL this has mostly been mitigated by the fact that every credit card transaction carries insurance and the banks are on the hook for phishing fraud and it is not in their interest to go after the CAs (at this point). The business of a CA no doubt looks rather simple to people who do not bother themselves with what it entails. But remember that the reason VeriSign was formed as a separate company in the first place was that no other business would. Not even RSA would risk being a CA on their own account. It might be possible to stampede or threaten the registrars into deploying DNSSEC on the basis that no liability showed up in the SSL case so DNSSEC must be safe, but that is hardly likely when the registrars are also being asked to give up their SSL reseller revenues. At the very least, to have any success with applying the SSL approach, ICANN would have to start engaging with the people who are asking these questions. I posed the question formally six months ago before giving a talk on this topic at the RSA conference this year. Richard Lamb was present at that talk, he knows that I have raised these issues and will continue to do so. The current ICANN proposal for DNSSEC is just that, a proposal. I am not raising these points to be awkward or obtuse. I do want to see DNSSEC deployed. But the way to do that in my view is to have less of the happy talk and start thinking about what the real constraints are. I have a plan which I believe meets the constraints as I currently understand them. What I do not yet know, and due to the prevailing 'happy talk' sentiment cannot know is that I have a complete set of constraints.