Re: draft-hollenbeck-grrp-reqs-06 [Was Re: Interim Meeting]

[Kent Crispin <kent@songbird.com>]

On Wed, Feb 14, 2001 at 06:58:02PM -0500, Sheer El-Showk wrote:
[discussion of using PKI methods]

It's interesting to note that this stuff was disccused for the CORE SRS
at great length, in the context of what were called "Zone Keys" - a zone
key is a public key associated with a zone that authorizes updates. 
Here's an informal paper I wrote a couple of years ago.  It may
contribute something to this discussion:


	             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. 




-- 
Kent Crispin                               "Be good, and you will be
kent@songbird.com                           lonesome." -- Mark Twain