> > > Thats what public keys are for. If you involve humans,
> >
> > It is a human who makes the decision to change registries. That
> > human contacts the registries involved, and says (via email or over
> > the phone, or via a certified letter, or whatever normal business
> > practice is) "I want to change".
>
> I think you miss the point.
>
> A public key should be associated with each domain. Then, when you
> want to change, you hand a PK signed statement to the new
> registry. That way, YOU control the domain, not the registry.
>
> Helps from a liability standpoint, too.
A nice fantasy.
But unfortunately, there isn't a PKI to support it. What does a registry
do when the customer says "my disk crashed and I lost my PK"? It
uses the customer's drivers license, or some other accepted form of
legal identification.
[snip]
> Since public key is used to talk to the CDB, no humans are needed at
> the CDB.
It's probably necessary that the registries and the CDB use PK.
However, (repeating myself for the third time) there isn't a PKI to
support customer-registry interactions, and there isn't going to be
one in a time frame of interest. Therefore the registries will need
current technology to establish their contracts with their
customers. That means a human contact.
> I'm afraid you have a lack of imagination about what is
> possible here.
Hmm. You implemented your first database system at age 16, and you
are still proposing the same solutions? Shall we get back to the GPS
based algorithms? :-) It is very seldom I am criticized for *lack* of
imagination.
But I do worry about you, -- in my experience many old database guys
fall into the "my only tool is a hammer, so every problem is a nail"
trap.
> Billing and contact information is used by the registry, not by the
> CDB, so that ends up being a matter of registry policy, not a matter
> of system design.
>
> HOWEVER, it is likely important that up to date and accurate
> information be kept at the CDB in case of a registry vanishing, or in
> case the CDB needs to contact the users of a failed registry (to
> inform them that they have to switch), to cut the whois database, and
> for other similar reasons.
Another approach to dealing with the failing registry problem is to
have a lifetime for every name in the CDB. When the registry commits
the name, it is for a specified period of time (the amount of time
that has been paid for). If the registry fails, it would be up to
the customer to find another before it expires. Otherwise we have
yet another function that the IANA takes on...
> > You argue that it should also be kept at the CDB; I argue that it
> > shouldn't,
>
> Why the hell not?
Perhaps I could reverse that question -- why do you think it should?
>
> > and that *if* it is, the data at the CDB is just a good-faith copy
> > -- the data at A is the master.
>
> "Master" is a matter of opinion. So long as its required to be kept up
> to date, I don't care what you call the "master". Call the copy kept
> on CP/M formatted 8 inch floppies the "master" for all I care.
>
> > Now, your comment that "authoritative" is really meaningless in the
> > context of whois data is quite interesting. I suppose you mean that a
> > registry could, for example, put whatever information for contact
> > information it wanted in the CDB, and just keep its private records
> > for billing purposes.
>
> No. I'm arguing that "authoritative" is meaningless. "Authoritative"
> means something in the context of, for instance, DNS records, because
> some servers are guaranteed to have the freshest data, and others just
> have cache.
*Exactly* the same for registries. The registry is guaranteed to have
the freshest data (and in fact this is true, by the definition of a
registry), and the CDB, at best, is a cache.
> However, in this context, the data at the CDB should be
> kept accurate. Whether the registry keeps a second database,
Regardless of what you would like, it is in *fact* the CDB that is the
"second database". The registry is the one that deals with the
customer. Any changes the customer makes happen at the registry
first. Or are you suggesting that all transactions go through the
CDB before the registry is involved?
> a
> different database, or anything else is of no concern. The only
> requirement is that the data at the CDB be *accurate*, in case it is
> needed.
As you point out in another post (your comment about maintaining
a proxy data for offshore hedge funds), clearly *you* don't believe
that the data in whois needs to be accurate, regardless of what you
are arguing here.
> > I was referring to the fact that the contract (cooperative agreement)
> > expires soon, and we would like it to be changed. That is, *contracts
> > can change*. We view the possible change in this case in a positive
> > light, but contracts can change for the worse, as well.
>
> Contracts can last a long time.
[nice example deleted]
> There is no rule that says contracts cannot last 150
> years if need be.
Nice example, but immaterial. Nobody is going to give a 150 contract here.
In fact, contracts will almost certainly be with relatively short
spans -- 5 years max. And in fact, it would be nuts to give out long
term contracts, because long term contracts can have real problems
when you need to make a change.
> > We as technical weenies are really incompetent in the legal arena.
>
> Speak for yourself. I'm not a lawyer, but the elements of contract law
> are really easy.
You know the saying "the man who is his own lawyer has a fool for a client"?
[snip]
> > > No. You need something to cut the masters that generate the DNS. You
> > > also want a central database containing authorization information on
> > > who can and can't switch a zone from one registry to another.
> >
> > OK. That's a record like this
> > - the domain nae
> > - who can switch a zone, and the location
> > of the whois data.
> > - for updating DNS
> > - for reservations
> >
> > No other information is necessary.
>
> Sorry, but you need all the information a new registry would require,
> and authentication data like public keys. If a registry is destroyed
> in a freak accident with all its personel, you need ALL the data the
> registry would have had about who owns what.
I agree that you need the public keys. I assumed that would be in
another, much smaller, database where information on registries was
kept. You clearly don't *need* all the contact information.
- --
Kent Crispin "No reason to get excited",
kent@songbird.com,kc@llnl.gov the thief he kindly spoke...
PGP fingerprint: B6 04 CC 30 9E DE CD FE 6A 04 90 BB 26 77 4A 5E
----------------------------------------------------------------------
Date: 21 Aug 1996 15:37:48 -0700
From: Simon Higgs
Subject: Re: yet more unworkable distributed design
At 12:37 PM -0400 8/21/96, Perry E. Metzger wrote:
>I would suggest that a public/private key pair be associated with each
>registry, and with each domain. The holder of the domain key would be
>able to do exactly one thing -- sign a request which could be
>countersigned by a filing registry requesting that a domain be
>switched to that registry. The registry keys would be used for all
>other requests, but would only have the ability to modify data
>associated with that registry.
>
>An interesting question arises for WHOIS style data, specifically old
>style NIC handles. Since a given handle might involve domains for
>several registries, the question of who gets to update the handle
>information gets hard. Perhaps we should abandon the old style NIC
>handles -- thoughts?
>
We need the handles to identify a specific record in a specific table.
Plus, there's no point in doing away with them as they are great time
savers when filling out templates.
Each record should get an extra field to store it's own authentication
"key". That key could be as simple as a From: address in email, to a PGP
key. The record would only get updated if the key information is present in
the update request.
One domain registration will contain four keys (owner/organization, admin,
technical, billing) from the domain record's sub-sets. The
owner/organization key unlocks the name server info and who the contacts
are, while the individual contact keys allow those individual contact
records to be updated. The owner/organization key (the key of a legal
entity such as a company as opposed to an individual representing a
company) would provide the overall authority and this would solve some of
the legal problems.
_____S_i_m_o_n___H_i_g_g_s_________________H_i_g_g_s___A_m_e_r_i_c_a_____
... "I'm fine - it's the others" ......... President/CEO ................
_____e-mail: simon@higgs.com _____________ http://www.higgs.com/ ________
... http://ds.internic.net/internet-drafts/draft-higgs-tld-cat-02.txt ...
----------------------------------------------------------------------
Date: 21 Aug 1996 15:51:12 -0700
From: Kent Crispin
Subject: Re: New Non-Shared TLD's Create More Monopolies
Perry E. Metzger allegedly said:
>
>
> Kent Crispin writes:
> > 3) It hinders the freedom of the registries to control access to the
> > information. For example, an "anonymous" registry could filter all
> > contacts through itself.
>
> If you want anonymity, operate your zone through a nominee. I run a
> couple of zones for offshore hedge funds -- it would be quite a
> challenge to find out who the owners are from the contact info (which
> is me or an employee and P.O. Boxes in places like the Bahamas.)
>
> We don't need anonymity via registries, and the mechanism you propose
> would be a hinderance.
It's almost precisely what you are doing -- you are acting as a proxy
registry, and filtering the contact data through yourself. Why is
it not a hinderance in your case?
> > 4) Having a centralized database with all contact information
> > aggregating data that doesn't need to be aggregated. This is a
> > privacy concern -- it is one thing to be able to find a particular
> > indivual contact -- it is quite another to know the name and address
> > of *every* network manager.
>
> You'll have to live with this sort of thing. If any of the data is
> public, it *will* all be collected, eventually. If you need privacy,
> as I said, you can get it.
But it can be made much more difficult by having it widely dispersed.
> > 5) A general political concern about passing as much authority and
> > control to the registries as possible.
>
> I don't see how managing a database gives the CDB power, especially
> when it is legally constrained. I mean, how much political power does
> the vital records office in your county have? I'd suspect that the
> answer is "none". You only get power when you have the power to
> control. The CDB doesn't CONTROL the information, it just STORES
> it. There is a world of difference. The CDB has *no discretion*.
You would agree, I think, that the database you describe would be
*valuable* -- that there are people who would pay fairly substantial
sums of money to obtain it -- at the very least we know that people
pay *lots* of money for mailing lists. And you would also agree, I
think, that money and political power frequently cluster. And I think
you would further agree the only reason, in your terms, "the CDB has
*no discretion*", is bcause of certain as yet undefined "legal
constraints" you wave your hands about.
So what I see is a potentially very valuable database being created --
as you have described it it is the authoritative [and please don't rag
on about the meaning of the word -- it means exactly what you
described for DNS] database for 1) DNS -- all zone updates flow from
this database 2) all whois information, 3) coordination between
registries, 4) authentication and authorization between registries,
and between it and root nameservers. It has to be, according to you,
extremly reliable, well-run, and efficient, probably replicated.
Regardless of your disingenuous claims to the contrary, this isn't a
database that is going to be run on a pentium in a closet at IANA. It
will cost money and staff to run it. The organization that runs it
will control an incredibly valuable chunk of the net.
Don't worry, you claim, there will be "legal constraints" that
prevent abuses.
Perhaps I am unduly concerned. But, with all due respect, I am not
comforted by your claims of legal knowledge. And even if I was it
isn't you that will be letting or specifying the contracts involved.
- --
Kent Crispin "No reason to get excited",
kent@songbird.com,kc@llnl.gov the thief he kindly spoke...
PGP fingerprint: B6 04 CC 30 9E DE CD FE 6A 04 90 BB 26 77 4A 5E
----------------------------------------------------------------------
Date: 21 Aug 1996 16:22:52 -0700
From: Michael Dillon
Subject: Re: yet more unworkable distributed design
On Wed, 21 Aug 1996, Simon Higgs wrote:
> We need the handles to identify a specific record in a specific table.
Sequentially assigned numbers will do that.
> Plus, there's no point in doing away with them as they are great time
> savers when filling out templates.
Then let's have a PERSON identifier that is stored at the CDB. When
designing the actual record layouts I favor the following technique:
Person table
- ------------
prs-ref long integer unique key
prs-id character*6 unique key
prs-surname character*20 key
prs-given character*20
prs-ref is the internally used unique key which is stored in any other
tables that need to contain a reference to person. It is never seen by
humans other than techie types. prs-id is only there for external human
use and is never stored in any tables. Thus a list of domains printed out
by the system might read as follows:
example.com ......... MD130
But the actual table entry for example.com contains the prs-ref code.
Thus the report program uses prs-ref to lookup prs-id in order to present
it to the humans and at some future date humans might use the prs-id to
look up information.
The advantage of this is that an object's name (in this case a person's
name) can be changed and an associated mnemonic lookup key can change at
the same time without any impact on existing stored data because the
mnemonic lookup key is not stored anywhere. The drawback is that if
old mnemonic lookup keys will be frequently used you must create an
old-new cross reference table and refer to it whenever a prs-id is
presented by a human being. However, in my experience, this cross
reference is handled quite well by humans without any need for it to be
implemented in the computer system.
> Each record should get an extra field to store it's own authentication
> "key". That key could be as simple as a From: address in email, to a PGP
> key. The record would only get updated if the key information is present in
> the update request.
Before going that route I would rather see us investigate the First
Virtual model. That's because most domain owners will never have a true
authentication key and email addresses can be spoofed. Thus the registry
must email a verification note anyway so why not do the authentication on
that part of the communication.
Michael Dillon - ISP & Internet Consulting
Memra Software Inc. - Fax: +1-604-546-3049
http://www.memra.com - E-mail: michael@memra.com
----------------------------------------------------------------------
Date: 21 Aug 1996 16:26:29 -0700
From: johnl@iecc.com (John R Levine)
Subject: Re: New Non-Shared TLD's Create More Monopolies
[re a CDB database]
>So what I see is a potentially very valuable database being created --
>as you have described it it is the authoritative [and please don't rag
>on about the meaning of the word -- it means exactly what you
>described for DNS] database for 1) DNS -- all zone updates flow from
>this database 2) all whois information, 3) coordination between
>registries, 4) authentication and authorization between registries,
>and between it and root nameservers. It has to be, according to you,
>extremly reliable, well-run, and efficient, probably replicated.
>
>Regardless of your disingenuous claims to the contrary, this isn't a
>database that is going to be run on a pentium in a closet at IANA. It
>will cost money and staff to run it. The organization that runs it
>will control an incredibly valuable chunk of the net.
Well, the domain zone files have to come from somewhere, and if the CDB
doesn't have enough info to generate them, we're back to the zillion way
merge. Remember, all this needs to be (and probably all it should be) is
the names and IP addresses of the servers for the domain. Whether those
servers are at the registry, the customer's site, or anywhere else doesn't
matter. Trying to collect the zone info on the fly returns us to the
million way merge problem. I don't see a privacy issue here (and if you ask
around you'll find I'm a major privacy paranoid) -- most of this has to be
published for the DNS to work at all. Other than the crypto keys that
authenticate the registries, I think all the CDB's info should be published.
Similarly, there needs to be enough info to generate the WHOIS file, but
again that's not a huge amount of info, just name and address of domain
holder (who as Perry notes may be a nominee) and some contact people. We
all need to dig into RWHOIS and whois++ to see how well either or both make
distributed whois maintenance possible.
I still think this a couple of pentia are plenty of horsepower, so long as
someone credible is doing the backups.
- --
John R. Levine, IECC, POB 640 Trumansburg NY 14886 +1 607 387 6869
johnl@iecc.com "Space aliens are stealing American jobs." - Stanford econ prof
----------------------------------------------------------------------
Date: 21 Aug 1996 16:27:23 -0700
From: Kent Crispin
Subject: Re: yet more unworkable distributed design, was New Non-Shared TLD's Create More Monopolies
John R Levine allegedly said:
>
> >> And, of course, it's inconceivable that any registry would ever backdate a
> >> registration for a valued customer, even though there's no way anyone outside
> >> the registry could ever tell. Naah. It would be wrong.
> >
> >1) Backdating couldn't happen with the protocols I described -- that
> >should be obvious if you think about them for two minutes. The
> >timestamp really is unforgable.
>
> Even if the timestamps are impossible to forge, it seems to me that you
> could easily use a replay attack. Just use a genuine time stamp from an
> hour ago or a day ago or a week ago or, for that matter, a month ago.
> ("Darn that uucp, kept getting busy signals.")
Your're right -- as I described it you could have that problem. It's
actually the box that receives the signal that does the signing. I
don't remember the exact details (I just skimmed it several months
ago), but here's a variation that I think will make the point: The
special purpose GPS timestamp device is built with an internal secret
key. You present it with a file to stamp. It concatenates the file
and the time/place stamp, and signs the result with it's secret key.
It's public key is of course well known to all concerned. This
variation requires that the box be tamperproof, like the atomic clock
scheme -- I think the Denning algorithm did not require something
being tamperproof.
Thanks for thinking about it :-)
> >2) There is another, similar, method of cheating that no protocol yet
> >described, centralized or not, can protect against. That's the
> >problem of pre-allocating a name. Nothing we have described prevents
> >a registry from assigning 5000 desirable names, setting up
> >nameservers for them, and reselling them later.
>
> That's true, and indeed the analogous problem has been a chronic problem in
> the 800 arena. I believe that there's a rule in the 800 biz that if you
> can't identify a customer who's using a number and you've had it reserved
> for more than a few days, you have to give it back. I hope a similar rule
> could keep the abuse down.
>
> You also have the problem of registry customers hoarding names, e.g. P&G's
> diarrhea.com and the names for sale by some domain name brokers. I don't
> see any way to solve that, but I also don't see that whether a domain is
> shared or not makes any difference to this problem.
Yes -- this problem is orthogonal to sharing. Policies could be
devised to try to deal with it.
As far as registries hording names, that could be deemed an abuse,
and cohort registries could sue for unfair business practices or
whatever.
- --
Kent Crispin "No reason to get excited",
kent@songbird.com,kc@llnl.gov the thief he kindly spoke...
PGP fingerprint: B6 04 CC 30 9E DE CD FE 6A 04 90 BB 26 77 4A 5E
----------------------------------------------------------------------
Date: 21 Aug 1996 18:31:11 -0700
From: "Dave Collier-Brown"
Subject: Re: New Non-Shared TLD's Create More Monopolies
Michael Dillon wrote:
| Anyway, let me rephrase my previous message. Yes I think it is necessary
| to get the database design done before the protocol design, but I think it
| is even more important to agree on a requirements document even if it is
| not formally published.
I'll try to contribute to this tomorrow: I have a mildly
abstract model (our usual one of Customer, Registry and Domain)
which I'm cranking through all possible states to see what
might happen, and therefor what the Coordinating Database
and any protocols might need to support.
- --dave
- --
David Collier-Brown, | Always do right. This will gratify some people
185 Ellerslie Ave., | astonish the rest. -- Mark Twain
Willowdale, Ontario | davecb@hobbes.ss.org, unicaat.yorku.ca
N2M 1Y3. 416-223-8968 | http://java.science.yorku.ca/~davecb
----------------------------------------------------------------------
Date: 21 Aug 1996 22:25:19 -0700
From: Simon Higgs
Subject: Re: yet more unworkable distributed design
At 4:19 PM -0700 8/21/96, Michael Dillon wrote:
>On Wed, 21 Aug 1996, I wrote:
>
>> We need the handles to identify a specific record in a specific table.
>
>Sequentially assigned numbers will do that.
>
Yeah, but they're instantly forgettable and therefore completely useless. I
can remember my NIC handle. I shouldn't have to memorize a credit card or
social security-length number.
>> Plus, there's no point in doing away with them as they are great time
>> savers when filling out templates.
>
>Then let's have a PERSON identifier that is stored at the CDB. When
>designing the actual record layouts I favor the following technique:
>
[SNIP]
How is this different from the whois contact id?
>> Each record should get an extra field to store it's own authentication
>> "key". That key could be as simple as a From: address in email, to a PGP
>> key. The record would only get updated if the key information is present in
>> the update request.
>
>Before going that route I would rather see us investigate the First
>Virtual model. That's because most domain owners will never have a true
>authentication key and email addresses can be spoofed. Thus the registry
>must email a verification note anyway so why not do the authentication on
>that part of the communication.
>
OK, so the update requested can be verified via email before it's
completed. Which is exactly why the key could be the From: address (or PGP
or any other method).
_____S_i_m_o_n___H_i_g_g_s_________________H_i_g_g_s___A_m_e_r_i_c_a_____
... "I'm fine - it's the others" ......... President/CEO ................
_____e-mail: simon@higgs.com _____________ http://www.higgs.com/ ________
... http://ds.internic.net/internet-drafts/draft-higgs-tld-cat-02.txt ...
----------------------------------------------------------------------
Date: 21 Aug 1996 22:29:52 -0700
From: Simon Higgs
Subject: Publish & Subscribe
How much validity is there for a publish & subscribe system between the
registry and the CDB? I notice several commercial DB packages (like Oracle
7, etc.) offer this with supposedly full conflict resolution. Comments?
_____S_i_m_o_n___H_i_g_g_s_________________H_i_g_g_s___A_m_e_r_i_c_a_____
... "I'm fine - it's the others" ......... President/CEO ................
_____e-mail: simon@higgs.com _____________ http://www.higgs.com/ ________
... http://ds.internic.net/internet-drafts/draft-higgs-tld-cat-02.txt ...
----------------------------------------------------------------------
Date: 21 Aug 1996 22:38:38 -0700
From: Michael Dillon
Subject: Re: yet more unworkable distributed design
On Wed, 21 Aug 1996, Simon Higgs wrote:
> >Then let's have a PERSON identifier that is stored at the CDB. When
> >designing the actual record layouts I favor the following technique:
> >
> [SNIP]
>
> How is this different from the whois contact id?
The whois contact id is internally generated within the Internic. I'm
suggesting a standard id code that will be used by all international TLD's
and maintained in the CDB.
> OK, so the update requested can be verified via email before it's
> completed. Which is exactly why the key could be the From: address (or PGP
> or any other method).
From addresses can be forged
And most people will never use a PGP key.
Michael Dillon - ISP & Internet Consulting
Memra Software Inc. - Fax: +1-604-546-3049
http://www.memra.com - E-mail: michael@memra.com
