Re: CORE Show Stopper

[Jeff Williams <jwkckid1@ix.netcom.com>]

Jim and all,

Jim Dixon wrote:
> 
> On Sun, 30 Nov 1997, Kent Crispin wrote:
> 
> > > > This issue has been known for a *long* time, and registrar collusion
> > > > is one of the central design concerns of the CORE registry design...
> > >
> > > It was?  I recall no discussion at all of this issue in Munich, New
> > > York, or on the RFP team's email list.  It was certainly not a central
> > > design concept.
> >
> > Then you weren't paying attention. I certainly made the point several
> > times in New York that one of the reasons for avoiding secret
> > components of the shared registry protocol was to avoid collusion -- I
> 
> I will repeat: I don't recall the idea being discussed, and I was one
> of the few people taking careful notes.

  I am glad tht you did.  I am also glad that there were some of our
folks
there doing the same.  Maybe we could compair notes here?
> 
> > probably used that very term (though I don't recall exactly), since I
> > have used it before.  Also, Munich, New York and the RFP list are a
> > tiny fraction of the debate that has gone on.
> >
> > But jeez, Jim, think.  Why do you suppose it's a *shared* registry? --
> > the whole point is to put the registrars in a competitive
> > relationship, and a great deal of thought has gone into making sure
> > that competition is maintained.  This aspect of it was argued at
> > vociferous length on the IAHC list, and at various times on the newdom
> > lists before that.  (Though I grant you the exact term "collusion" was
> > not used -- the first use of that term that I recall was in a short
> > paper on dispute resolution I circulated on the PAB list -- it had a
> > section titled "Collusion", and the basic conclusion was that the best
> > way of avoiding collusion was avoiding secrecy in the Shared Registry
> > Protocol.)
> >
> > As far as the RFP team is concerned: of course not every aspect of
> > the design was discussed -- great portions of the design were
> > determined by discussions that occured long ago, and the team accepted
> > that prior work without comment.  In particular, as you know, I wrote
> > the technical specifications section, people reviewed what I wrote, made
> > some comments which were incorporated, and let a great deal of it pass
> > without comment.
> 
> I don't think that we should get too far into this.  The technical
> specification section began life as the notes that I took in Munich.
> Dave C wordsmithed these a bit into the technical specs produced in
> New York.  You took the wordsmithing further.
> 
> > The particular features of the design that were explicitly concerned
> > with the possibility of collusion were things like:
> >
> > 1) the basic notion of a shared registrary
> > 2) the use of digital signatures on all transactions and replies,
> > thus giving every registrar a complete non-repudiatable record of all
> > transactions with CORE.
> 
> Transactions with CORE generate charges.  The primary purpose of
> digital signatures is to provide proof that the registrars actually
> placed the orders concerned.

  Yes, and a good idea.  Question is are they going to use DES or
what?  Back on the old IAHC-Discuss list I believe the need for
digital signatures was dismissed as not necessary (See archives).
Instead just authentication, login and password was perposed.
> 
> > 3) the insistance on complete openness of the transaction logs for
> > the CORE database.
> >
> > Anti-collusion definitely WAS a central design concept.
> 
> People were very concerned about CORE being impartial between
> registrars.  This did indeed come up again and again.  There was
> indeed concern about collusion, but not collusion between registrars.
> People were concerned about someone at CORE rigging the process
> to some particular registrar's benefit.  This is a much more serious
> threat than registrar-registrar collusion, particularly <ahem> to the
> registrars who are paying for the development of the CORE software.

  Agreed in general, and there are many diffrent ways to play this
shell game as well.  
> 
> >                                                         As I said, I
> > wrote the technical specs, and anti-collusion was something I was very
> > conscious of while I was doing it.  Anti-collusion has been a concern
> > of mine (and others) for a long time before you were ever on the
> > scene.
> 
> There were many people involved in producing the technical specs.
> 
> >        It may be something you haven't thought much about, but it's
> > generally bad practice to generalize your own lack of thought to
> > others.
> 
> Sure.  Equally, Kent, when you fail to see the large problem and
> concentrate on the small, it is understandable but bad practice.

  Also potentialy dangerous as well.
> 
> --
> Jim Dixon                                                 Managing Director
> VBCnet GB Ltd                http://www.vbc.net        tel +44 117 929 1316
> ---------------------------------------------------------------------------
> Member of Council                                                 President
> Internet Services Providers Association                       EuroISPA EEIG
> http://www.ispa.org.uk                              http://www.euroispa.org
> tel +44 171 976 0679                                     tel +32 2 503 2265
> 

Regards,

-- 
Jeffrey A. Williams
DIR. Internet Network Eng/SR. Java Development Eng.
Information Eng. Group. IEG. INC. (Soon to be INEG. INC) Stay tunned! 
Phone :913-294-2375 (v-office)
E-Mail jwkckid1@ix.netcom.com

Wisdom:   "One who knows others is wise,
           one who knows himself is enlightened."
           Lao Tzu