---------------------------------------------------------------------- Date: 12 Aug 1996 00:09:35 -0700 From: Kent Crispin Subject: Re: business model for shared tlds John R Levine allegedly said: > > >I don't see a great deal of human intervention in the merge -- I > >would expect the whole process to be done automatically. Human > >intervention is really only necessary when there are decisions to be > >made, and I don't see any discretionary behavior anywhere. > > What do you do when two registries give you conflicting data for the same > domain? Since this is an update from a master to a non-master, the master has precedence. > When the data from a registry has a syntax error? (Do you throw > out the bad record, the entire domain with the syntax error, try and fix it, > something else?) This is data in a coordination database, which has a trivial syntax, it is being automatically pulled from one database and transmitted to another. No human intervention at all. Any syntax errors would be either a programming bug or transmission error. Bugs would have to be fixed, transmissions errors should be handled ok by the network protocols. If not, a checksum and retransmission should eliminate all but a tiny fraction. > When the data from a registry is missing? (Leave it out, > use yesterday's version, something else?) My vote would be to use yesterdays version. :-) > Again, it's the scaling problem. > If there were three registries, you could fix any problems with a phone call > or two. With a thousand registries, the chances of a few of them sending > you bogus data is very high, and the chances of finding the appropriate > people and working things out quickly considerably less. > > >In fact, I'm not sure I think having every ISP be a registry for every > >domain would be a good thing at all -- a good reason to make the cost > >of entry fairly high -- I have been thinking in terms of $2500 entry > >fee, and $1000/year thereafter. That would keep all but very large > >ISPs from being registries for every TLD under the sun. > > Indeed. Instead of having 10,000 registries, you'll only have 1,000 but > that's still far too many to play round robin. I think even 25 would be a > problem. OK, OK. :-) From a theoretical standpoint perhaps I could argue on, but I don't want to waste time, and the practical issues seem formidable. I really do want to get a working solution that we could actually set up an experiment with in the next few months, and it is absolutely clear, even to a stubborn old coot like me, that we couldn't solve these issues in that time frame. :-) I think we could profitably move on to a more detailed discussion of the light-weight registries (LWRs). Perry suggests that there could be just one (perhaps replicated for reliability) for all the TLDs, controlled by the IANA or subcontractors, funded by licensing fees. I see some merit to this model, and would like to explore it a little further. Let's see -- some issues: How does the LWR relate to DNS? Authentication? Actual protocol for communicating with the LWR? Perhaps people would care to comment on these, and anything else that crosses their mind? - -- 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: 12 Aug 1996 07:01:40 -0700 From: xdat11@S-IL06-B.corp.mot.com Subject: RE: FW: Re: FW: Shared TLD's Will NOT Work Bob, Can't you do this now with your SLD? Dave >---------- >From: Bob Allisat[SMTP:bob@ns1.vrx.net] >Sent: Sunday, August 11, 1996 8:24 PM >To: KOON SANG LIM >Cc: newdom@ar.com; shared-tld@higgs.net >Subject: Re: FW: Re: FW: Shared TLD's Will NOT Work > > > >On Sun, 11 Aug 1996, KOON SANG LIM wrote: >> Well, if you are arguing for a free,non-profit, charitable type of >> services then I believe you need not worry about any commercial >> competition! Your TLD will be as good as exclusive or non-shared! >> However, you still did not address the point how the registries of >> a shared-TLD can not be operated as humanly as an exclusive one. > >Non-shared TLD's that are >geared to specific groups, >professions or organizations >will gear all of their procedures >to their clients. For example >World TeleVirtual Network will >organize it's entire .WTV TLD >registry and directory services >to independant and small Web >Television clients. > >When the client picks up the >phone or sends E-mail or registers >they will be dealling with a closed >house process. We can control for >quality and content at every step. >Introduce third parties into the >picture and the circle is broken >by people who don't have a clue >about the clientelle or the >specific media. > >In order to provide the requisite >high quality of service we will >not allowISP's or other, generic >TLD's to handle our clientelle. >They will bungle the job no matter >how many charters we send them. > >TeleVirtually Yours, > >Bob Allisat tor@wtv.net >Director, >World Televirtual Network http://www.wtv.net > ---------------------------------------------------------------------- Date: 12 Aug 1996 07:51:40 -0700 From: perry@piermont.com Subject: Re: business model for shared tlds John R Levine writes: > >I don't see a great deal of human intervention in the merge -- I > >would expect the whole process to be done automatically. Human > >intervention is really only necessary when there are decisions to be > >made, and I don't see any discretionary behavior anywhere. > > What do you do when two registries give you conflicting data for the same > domain? I believe the trick is, again, to assume a central databse. If you load the top level name servers off of the lock database, there is no room for that conflict to happen. Perry ---------------------------------------------------------------------- Date: 12 Aug 1996 07:54:32 -0700 From: perry@piermont.com Subject: Re: CONSENSUS PN TOP LEVEL DOMAIN NAMES Dan Busarow writes: > On Sun, 11 Aug 1996, Kent Crispin wrote: > > plain-text passwords flying around the net, either. The most > > straightforward model would be for each registry for a TLD to be given > > a public/private key pair to authorize reservations for that TLD. > > However, PK solutions with decent key sizes demand significant CPU, > > and a denial-of-service attack is quite easy to imagine... Just to mention: with the use of anti-clogging tokens a la the Photuris protocol, its hard to mount a successful denial of service attack that doesn't result in someone being caught. Personally, I'd say that this portion of the problem is fairly easy -- we have a number of available cryptographic protocols to steal. GSS-API stuff comes right to mind. > Two methods come to mind. > > 1) a virtual private network using on the fly encryption. Off the > shelf hardware and virtually no performance hit at T1. Only protects the link, not the underlying data. A lose, for the same reason you don't use link encryption on SMTP -- you use PEM or PGP or S/MIME or MOSS or whatever to protect the message itself. > 2) Digital certificates. Both server and client auth are now available > but I don't really know how much CPU they take to authenticate. Its not a real issue for the scale of registration rates we are talking about -- tens of thousands to at most hundreds of thousands a week. Perry ---------------------------------------------------------------------- Date: 12 Aug 1996 07:54:37 -0700 From: perry@piermont.com Subject: Re: CONSENSUS PN TOP LEVEL DOMAIN NAMES Dan Busarow writes: > On Sun, 11 Aug 1996, Kent Crispin wrote: > > plain-text passwords flying around the net, either. The most > > straightforward model would be for each registry for a TLD to be given > > a public/private key pair to authorize reservations for that TLD. > > However, PK solutions with decent key sizes demand significant CPU, > > and a denial-of-service attack is quite easy to imagine... Just to mention: with the use of anti-clogging tokens a la the Photuris protocol, its hard to mount a successful denial of service attack that doesn't result in someone being caught. Personally, I'd say that this portion of the problem is fairly easy -- we have a number of available cryptographic protocols to steal. GSS-API stuff comes right to mind. > Two methods come to mind. > > 1) a virtual private network using on the fly encryption. Off the > shelf hardware and virtually no performance hit at T1. Only protects the link, not the underlying data. A lose, for the same reason you don't use link encryption on SMTP -- you use PEM or PGP or S/MIME or MOSS or whatever to protect the message itself. > 2) Digital certificates. Both server and client auth are now available > but I don't really know how much CPU they take to authenticate. Its not a real issue for the scale of registration rates we are talking about -- tens of thousands to at most hundreds of thousands a week. Perry ---------------------------------------------------------------------- Date: 12 Aug 1996 07:54:55 -0700 From: perry@piermont.com Subject: Re: authorization Kent Crispin writes: > Something like this sounds much, much better. > > I take it you mean send(msg+md5(xor(msg,key))), rather than > send(msg+xor(md5(msg),key)). The latter would trivially reveal the > key... 1) Rather than inventing your own, stick with well cryptographically analyzed MACs, like HMAC. 2) Public key methods are far superior in this instance, and no, they won't be too much of a CPU load. Perry ---------------------------------------------------------------------- Date: 12 Aug 1996 08:55:23 -0700 From: Dan Busarow Subject: Re: CONSENSUS PN TOP LEVEL DOMAIN NAMES On Sat, 10 Aug 1996, Perry E. Metzger wrote: > Dan Busarow writes: > > The new incarnation of IANA. I believe consensus has been reached that > > IANA be reorganized as either a Swiss corporation or an agency of the ITU. > > Their only interest is to see that the global name space remains pure. > > Really? From whom was there a consensus of that sort? Back on the original newdom I think. There was a long discussion on the merits of ITU vs Swiss corp. vs ... I think the organization chart was ITU -> ISOC -> IANA when the discussion died down. My memory may be colored since I like this type of organization. Dan - -- Dan Busarow 714 443 4172 DPC Systems dan@dpcsys.com Dana Point, California 83 09 EF 59 E0 11 89 B4 8D 09 DB FD E1 DD 0C 82 ---------------------------------------------------------------------- Date: 12 Aug 1996 11:16:36 -0700 From: Kent Crispin Subject: Re: authorization Perry E. Metzger allegedly said: > > > Kent Crispin writes: > > Something like this sounds much, much better. > > > > I take it you mean send(msg+md5(xor(msg,key))), rather than > > send(msg+xor(md5(msg),key)). The latter would trivially reveal the > > key... > > 1) Rather than inventing your own, stick with well cryptographically > analyzed MACs, like HMAC. Agree totally -- it is far too easy to make a mistake. > 2) Public key methods are far superior in this instance, and no, they > won't be too much of a CPU load. I regularly use ssh, and on a small machine it adds up to several seconds wall clock time for a single authentication, depending on the horsepower of the machines involved (it doesn't take so long on a Cray). So I'm not sure I agree about the CPU load for PK authentication. Once logged in, however, the stream ciphers in ssh produce no noticable overhead, even for X applications. John's point about pre-authentication, with shared secret keys, makes the issue somewhat moot -- it isn't really necessary to authenticate on every transaction, if the stream cipher keys are relatively long-lived (several hours). However, my thinking is turning to the practical issue of getting an experimental shared TLD going. A completely off-the-shelf implemention would involve a small database server (a Pentium machine with a few gigs of disk, perhaps running Linux or BSD, with ssh installed, housed in a closet at ISI. - -- 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: 12 Aug 1996 11:50:41 -0700 From: Kent Crispin Subject: Re: Shared AND Exclusive TLDS !!! Simon Higgs allegedly said: > > At 10:28 AM -0700 8/11/96, Kent Crispin wrote: > > >Simon Higgs allegedly said: > >> [snip] > >> And these provisions were in draft-higgs-tld-cat-02.txt a long time ago. > > > >They were indeed, and it is on my list to go back and reread your > >draft. One of the problems I had with it was that it supported a > >larger set of monopoly TLDs than I would like, though. Perhaps > >you would be interested in further discussion of that point? > > > > This is a false assumption on your part. Which one? :-) > The majority of the domains in the > draft form a shared pool of new TLDs based upon previous discussions. > Remember these points did have consensus when they were discussed: > > 1. Creating TLDs to justify the existance of a registry is the wrong > solution. > 2. Registries serve the TLDs. Not the other way around. > 3. Creating TLDs and registries are two seperate issues. Got a chance to review your draft over the weekend -- generally excellent work, BTW, except you persistently misspelled "categories" - -- and the sections that caught my eye earlier were "5.2 Specialized TLD Class" and, even more, "5.3 Corporate TLD Class". I interpreted these to be monopoly TLDs, and, if I had my druthers, I would disallow corporate TLDs entirely, and put stronger controls on "specialized TLDs". Your draft was completed before I got involved in the list, 'tis true. I am amazed to hear that there was consensus on anything... I would like to use potentially large gobs of stuff from your draft as a part of a draft strictly related to shared TLDs, so I moved this over to the shared-tld list -- like I said, I think you did an excellent job, and a lot of the material does directly related to just shared tlds. Given the legal miasma that has developed over these issues, I think there should be some changes in the proposed oversight structure -- things like the Board of Trustees for a TLD, and so on. And of course there are a number of technical details to be discussed. So would you be game for working on a new draft specifically concerning shared TLDs? - -- 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: 12 Aug 1996 12:03:39 -0700 From: perry@piermont.com Subject: Re: authorization Kent Crispin writes: > > 2) Public key methods are far superior in this instance, and no, they > > won't be too much of a CPU load. > > I regularly use ssh, and on a small machine it adds up to several > seconds wall clock time for a single authentication, depending on the > horsepower of the machines involved (it doesn't take so long on a > Cray). So I'm not sure I agree about the CPU load for PK > authentication. Doing an SSH like calculation is pretty fast on a modern CPU like a Pentium-133. Even if it were two or three seconds, though, this is not a problem -- are people expecting to do substantially more than ten thousand registrations per day? We shouldn't cripple our long term security based on a desire to use crusty i386s running Linux as registries. Put another way, if large sites handle public key transactions on every SSL based HTTP connection they do for credit card orders, we should have no trouble using P/K. > Once logged in, however, the stream ciphers in ssh produce no > noticable overhead, even for X applications. John's point about > pre-authentication, with shared secret keys, makes the issue somewhat > moot -- it isn't really necessary to authenticate on every > transaction, if the stream cipher keys are relatively long-lived > (several hours). Again, from a security standpoint securing the channel is NOT what you want. You need to secure the DATA. This is the distinction between an encrypted session handler (as in secure telnet) and digitally signed/encrypted messages (a la PEM). We need to be securing requests with digital signatures, not securing the links. > However, my thinking is turning to the practical issue of getting an > experimental shared TLD going. A completely off-the-shelf > implemention would involve a small database server (a Pentium machine > with a few gigs of disk, perhaps running Linux or BSD, with ssh > installed, housed in a closet at ISI. Probably a good idea to actually try this, yes. Perry ---------------------------------------------------------------------- Date: 12 Aug 1996 13:53:57 -0700 From: johnl@iecc.com (John R Levine) Subject: Re: authorization >I take it you mean send(msg+md5(xor(msg,key))), rather than >send(msg+xor(md5(msg),key)). The latter would trivially reveal the >key... Yup, sorry if I was unclear. - -- 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: 12 Aug 1996 14:58:25 -0700 From: Kent Crispin Subject: Re: CONSENSUS PN TOP LEVEL DOMAIN NAMES Perry E. Metzger allegedly said: > > > Dan Busarow writes: > > On Sun, 11 Aug 1996, Kent Crispin wrote: > > > plain-text passwords flying around the net, either. The most > > > straightforward model would be for each registry for a TLD to be given > > > a public/private key pair to authorize reservations for that TLD. > > > However, PK solutions with decent key sizes demand significant CPU, > > > and a denial-of-service attack is quite easy to imagine... > > Just to mention: with the use of anti-clogging tokens a la the > Photuris protocol, its hard to mount a successful denial of service > attack that doesn't result in someone being caught. Perhaps after it's been in use for a while. > Personally, I'd say that this portion of the problem is fairly easy -- > we have a number of available cryptographic protocols to > steal. GSS-API stuff comes right to mind. GAAKK!! Pardon me. It will only take a moment to clean up the keyboard. > > Two methods come to mind. > > > > 1) a virtual private network using on the fly encryption. Off the > > shelf hardware and virtually no performance hit at T1. > > Only protects the link, not the underlying data. A lose, for the same > reason you don't use link encryption on SMTP -- you use PEM or PGP or > S/MIME or MOSS or whatever to protect the message itself. Actually, some sort of secure email interface might not be a bad approach for the Pentium Prototype LWR server. Are you aware of PD versions of s/mime or moss? Of course, a perl script that ran pgp and sendmail could be thrown together real quickly. > > 2) Digital certificates. Both server and client auth are now available > > but I don't really know how much CPU they take to authenticate. > > Its not a real issue for the scale of registration rates we are > talking about -- tens of thousands to at most hundreds of thousands a > week. I'm still not convinced of that, for a variety of reasons, but it certainly wouldn't be an issue for the short term. Long term, experience will give us unambiguous information about where optimization might be needed. - -- 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: 12 Aug 1996 15:15:04 -0700 From: perry@piermont.com Subject: Re: CONSENSUS PN TOP LEVEL DOMAIN NAMES Kent Crispin writes: > Perry E. Metzger allegedly said: > > Just to mention: with the use of anti-clogging tokens a la the > > Photuris protocol, its hard to mount a successful denial of service > > attack that doesn't result in someone being caught. > > Perhaps after it's been in use for a while. I don't understand. > > Only protects the link, not the underlying data. A lose, for the same > > reason you don't use link encryption on SMTP -- you use PEM or PGP or > > S/MIME or MOSS or whatever to protect the message itself. > > Actually, some sort of secure email interface might not be a bad > approach for the Pentium Prototype LWR server. Are you aware of PD > versions of s/mime or moss? Of course, a perl script that ran pgp > and sendmail could be thrown together real quickly. The only problem with that is it isn't fully on-line -- it would all be fairly slow. A quick ad hoc protocol might actually be substantially better. Perry
