[4247] in cryptography@c2.net mail archive
Re: Using crypto to solve a part of the DNS/TM mess
daemon@ATHENA.MIT.EDU (Michael Froomkin - U.Miami School )
Mon Mar 1 12:06:53 1999
Date: Mon, 1 Mar 1999 10:42:42 -0500 (EST)
From: "Michael Froomkin - U.Miami School of Law" <froomkin@law.miami.edu>
To: cryptography@c2.net
Cc: coderpunks@toad.com
In-Reply-To: <199902272221.XAA23521@replay.com>
On Sat, 27 Feb 1999, Anonymous wrote:
> One way to approach this is to have an organization which will verify
> contact information. A potential domain name registrant supplies his
> contact information in the form of name, address, phone number, or other
> identifcation. This information is verified by the usual means.
I think the cost of this is prohibitive. The fact is that the enormous
majority of DN registrations are honest and non-problematic. And the
number of registrations continues to increase at the usual internet
speeds. Verification only makes economic sense when there is someone Out
There who feels aggrieved.
> Then the contact-verifying organization supplies a BLIND signature on
> the contact information. We can call this blind signature a
> "certified contact token".
Once there has been a "challenge" do we need all this? The answer *might*
be 'yes' in that there can be malicious challenges (e.g. a government
trying to locate dissidents), although this is so far a relatively rare
case.
> This signature is such that it is verifiable by any third party as
> being issued by the contact-verifying organization, but it is blinded
> so that there is no hint about what data was signed. There are
> various cryptographic methods (simplest being cut and choose) to
> ensure that the proper data has been signed, without the resulting
[sensible stuff deleted]
>
> > 2) registrants who provide false contact details can be detected upon a
> > challenge by a third party, but the third party does not get to know
> > accurate contact details.
>
> Third parties can verify that names are registered with valid certified
> contact tokens.
>
> There are a couple of possible frauds here.
>
> One is for someone to get more than one certified contact token. This
> could be done simply by having two addresses or two phone numbers. We
> can't do much about this, and it is possible in any system. We could
> begin to address it by requiring more information in the contact
> verification process.
Yes, but my mind boggles a bit as to WHAT you could reasonably ask for in
a process where the registrant could be anywhere in the world....
> Another fraud is to buy someone else's certified contact token and use
> that for some of the registrations. This could be addressed in part
> by making it expensive to purchase these tokens (and then relatively
> cheap to register domain names). Ultimately, though, Alice buying and
> using Bob's certified contact token is essentially equivalent to Alice
> paying Bob to register names on behalf of Alice. We can't stop people
> from cooperating with each other.
>
Thanks, but I don't want to build a global ID system (bad, bad, bad) just
to solve this relatively small problem....
>
> > 3) it is possible for a third party who wishes to challenge the
> > registration of Domain DN1 to find out how many other domains have been
> > registered by the owner of DN1, and what they are, without necessarily
> > finding out the identity of the registrant.
>
> In this system, all registrations by a single person would use the same
> certified contact token. This would allow all third parties to see when
> multiple names are being registered by the same person.
>
Again, if we start with the model that we want easy, cheap, instant
registration (that's what the customers want and are used to), then we
can't front-end all this. The serious processing/checking can't start
until the challenge, I think.
A. Michael Froomkin | Professor of Law | froomkin@law.tm
U. Miami School of Law, P.O. Box 248087, Coral Gables, FL 33124 USA
+1 (305) 284-4285 | +1 (305) 284-6506 (fax) | http://www.law.tm
--> It's warm here. <--
