Re: Transfering a domain

[davidk@ISI.EDU]

Kent,

> Kent Crispin writes :
> 
> Here's a somewhat different scheme -- since you apparently believe 
> that the possibility of the current registrar changing a users key is 
> not a concern, because it would be visible.

Let's say it a bit different. It is a concern. It would be nice if this
problem could be eliminated, however I think that keeping the data public
is sufficient for having a system that will work for our needs although
it is not completely satisfactury (but who can build a system that is
satisfactory in every sense?)

> When a domain is created, the end user supplies a public key.  This 
> public key and other info is added to DNS by the registrar.  The 

There is a slight problem here or I didn't understand your last sentence.
The repository OR the end-user are the only ones that could (should) add
the data to the DNS since the end-user runs primary for its own site and
the repository primary for the TLDs. The registrar should have no power
over the keys since it is the weak part in the chain. The registrar could
go out of business and the public keys could be unavailable at the same
time (The end-user could also go out of business but then the domain
will simply time-out after a year in the repository).

The end-user user could put the public key in DNS themselves (or in any
other database that is running on the end-users *own* machines). They
will need to setup their (primary) nameservers anyway and it solves the
concerns over changing the public key by anybody else. However, this
scheme has flaws since the end-users machine could not be very well
reachable in case of a DNS/ISP change ...

Conclusion: the public keys should be stored at a location that is in
control of the repository whether it is DNS or a simple database.

> registrar emails the end-user a digitally signed listing of the info 
> in DNS, so the user can guarantee that it was set up correctly.  This 
> registrar is noted in DNS as being the registrar representing the 
> user, and thus is authorized to make changes on the user's behalf.  
> This is my current model, and what I have implemented in my 
> Ultra-lightweight registry.

As I said before: your scheme and mine don't differ that much ;-). The
algorithm that you describe here can be used in both schemes. The main
difference is that you want to use DNS as the database and I would rather
like to use a very small high speed and simple database for generating
the zone files. One of the reasons I would do it that way is that I
expect that it is easier, faster and more crash resistant to add data to
a simple database then directly editing the zone files when an update in
the repository comes in. At the same time I already said that I would
prefer dumping the repository data in DNS for public review instead of
running a simple whois database at the repository.

My main issue was that we need a small, fast and low-cost central
repository and a strong authority for the user that supercedes the
authority of any registrar. I think that your and my scheme allow for
that although they both have their own merits and problem scenarios.


> Now we add the following: suppose the user wants to make a change.  
> The user can contact *any* registrar for the domain, indicating the 
> desired changes.  The new registrar notes that it isn't the current 
> registrar representing the domain, so it sends an "update" 
> certificate to the user, which the user signs and returns.  The new 
> registrar countersigns the certificate, and sends it to the dns upate 
> process, which checks the registrars sig, notes the user's sig, 
> checks it against the one stored in DNS, and does the update if it 
> works.

It can only check the signature under all conditions if the public key is
maintained by either the repository or the end-user itself. The public
key will not be retrievable when the registrar goes out of business and
runs primary for the data-set that it maintains. You could circumvent
this by forcing the repository to act as a backup but then you can as
well store the data centrally from the start ...

> The representing registrar acts as a fail-safe, in case the user 
> looses their key, since whichever registrar is so designated can 
> update  records without the users key being supplied.  But the user 
> always gets a signed certificate indicating the state of DNS.

My scheme could steal this feauture from yours :-) and will then have the
same advantage as well as the flaw: The registrar can help in case a
private key is forgotten but the registrar could also make a lot of
trouble when changing the public-key unasked for:

The designated registrar may always make changes without the end-users
signature BUT the end-user can override this by going to another registar
and sending a message that is signed by the other registrar and the
end-user (note that there are all kinds of variants possible for the
different kinds of data...)
 
> A serious dispute would still have to go to a central authority.

Yup, we can of course only try to minimize the amount of disputes (This
is another reason why a skilled administrative person at the repository
site is a good idea, engineers are not always the best mediators ;-)).

Then at last:

I appreciate that you pointed out the weaknesses in my scheme, it is a
challenge to come up with a better proposal each time. I hope that my
comments will do the same for you ;-).

David K.
PS  Note that English is not my native language and that I might
    sometimes sound a bit harsher then intended.
---