Another boring boring technical document Pros and Cons of NULL Zone Keys This document compares two alternative models for the registrar-registry protocol. The first model is the "Optional Zone Key" (Optional) model. The second is the "Mandatory Zone Key" (Mandatory) model. 1. Common assumptions Both models assume that 1) a domain record in the registry db has a field called "zone key" that contains a cryptographic key that can be used to verify digital signatures. 2) there is a "current registrar" field in the domain record that identifies the registrar currently representing the domain. A database of corresponding registrar keys is kept, so that registrar signatures may be verified. 3) a registrar signature is necessary for any transaction. 4) in addition, if there is a non-NULL key in the "zone key" field, any transaction for that domain *must* have a valid "zone signature". Furthermore, both models have a serious potential for disputes to arise when a user without a zone key wishes to change registrars. 2. Optional Zone Keys In this model a domain record may have a NULL zone key. In such a case, only the registrar signature is checked. If the request is not correctly signed by the registrar identified in the "current registrar" field, the request is ignored. The primary advantage of this model is simplicity. The primary problem with this model is that changing the value of the "current registrar" field cannot be done without either the cooperation of the current registrar, or involving a dispute that goes to the registry. More fundamentally, however, this is really just a manifestation of the fact that the domain owner has *no* mechanical(*) way of proving his identity. (*) A "mechanical" method is something that can be accomplished without involving human beings in the loop. 3. Mandatory Zone Keys In this model, *every* domain record in the registry db is required to have a unique zone key. Every request to modify data for the domain must be signed by that key. Since it is realized that the majority of domain owners do not and will not provide a zone key, and will not sign their requests, in the Mandatory model registrars are required to generate unique private keys for such customers, install such keys as the zone key, send a copy of the key back to the customer, and securely keep a copy for the customer. The primary advantage of this model is that every customer has available to them a mechanical method to change registrars, without involving the old registrar. However, there are several significant problems: 1) there is no simple, secure way to send the generated private key back to a user who doesn't use public key (PK) cryptography. 2) Since, by construction, the users involved are not knowledgable about PK and digital signature, they are unlikely to properly protect and preserve the key sent back to them. 3) Also, these users are unlikely to make use of the opportunity offered to them, since they would have to climb a learning curve to do so. 4) Assuming the user does learn about digital signatures, and wants to change registrars, the old registrar still has the zone key -- the user has to change the zone key, as well. 5) The big one -- every registrar has to *securely* maintain a database of private keys. While this can be largely automated, it adds a great deal of complexity to do so, and opens up other liability issues. 4. Disputes The interesting case is when a user who does not have (or has lost) a zone key wants to change to a different registrar. This is because the simplest way for a user to handle a disagreement with a registrar is to go to another registrar. With the Optional model there are two classes of users: 1) those who knowledgably use digital signatures, and 2) those who do not use digital signatures at all. With Mandatory model there are three classes of users: 1) those who knowledgably use digital signatures, 2) those who don't receive, or simply won't learn to use their private key (some customers may very well elect to not get their private key, since it will have to be sent in the clear if the customer doesn't already have PK technology under command), and 3) those who have received a private key from their registrar, and keep it, don't know how to use it, but could learn if necessary. Note that the description of classes 1 and 2 are essentially the same under both models. Class 1 (knowledgable digital signature users) cause very little problem to either model. I expect the size of class 1 to be slightly larger in the Mandatory model than in the Optional model (because there will be slightly more incentive to learn about digital signatures), but probably not significantly larger. Class 2 users comprise the largest class in either model, though we can expect the Mandatory model to have a significantly lower percentage of class 2 users than the Optional model (the class 3 users have to come from somewhere). It is my belief that, from a policy and dispute resolution point of view, class 2 users are essentially identical in both models. Both models will need to devise a non-mechanical inter-registrar domain transfer protocol for class 2 users, and the existence or non-existence of a zone key is the most trifling of technical details for this protocol. While the policy and dispute resolution procedures will be very similar, there is substantially less incentive for a registrar to try to "lock in" customers under the Mandatory model. This is because a registrar will have to assume that the user has a zone key and can change registrar independently. However, in *any* case the incentive for a registrar to lock in customers will be very low. One of the most widely trumpeted characteristics of the gTLD registries is domain name portability. Any registrar with a pattern of interfering with this property will certainly be in conflict with the gTLD MoU, and such a pattern will quickly be noticed and reported by customers. The consequences would be dire, the reward very small. Class 3 users are unique to the Mandatory model. The problem they present is key management and consulting load. Not only will the registrar have to worry about sending private keys in the clear to their customers (with whatever liability a clever lawyer can make of it), but they will be duty-bound to answer questions about the use of that key. There is also a class of disputes/liabilities involved in maintaining a key ring on behalf of a customer. A compromised key allows modifications to the domain; but there is no way of telling where that modification came from. The thief can send a modification request to any registrar, and it will be accepted without question. So a user who screws up their own domain can claim that the registrar exposed the key, and someone else (a key thief) did the damage. In general, it would be very hard for a registrar to prove that they did *not* expose the keys -- the registrars employees need to sign requests on behalf of their customers who don't use keys, so the security of the key database is always going to be a problem. Consider the anonymous, untraceable damage a disgruntled registrar employee could cause. Of course, in the Optional model a disgruntled registrar employee can cause damage as well, through misuse of the registrar key (which employees will need to access). However, it is *much* easier to change a single registrar key when an employee leaves, than it is to change thousands of zone keys. [Technical note -- this is why you store a registrar ID in a domain record, instead of a registrar KEY...] 5. Summary The issues are complex, unfortunately. I have a significant bias towards the optional model, and I am afraid I may have slanted this document. But, even so, I have to say that I think that scale clearly tips toward the Optional model. The disputes it allows are still largely present in the Mandatory model (though perhaps in somewhat diminished numbers), but it is simpler for the registrars to deal with, and the Mandatory model creates potential for a whole new class of disputes. If you have read this far, let me encourage you to make some comments.