Bill proposes an alternative DNS system to allow third party
verification of server integrity, which I'll comment on below.

A meta-comment though, is that my earlier proposal (as well as Bill's
proposal) are essentially integrity verification functions on the
domain database.  They don't prevent rogue behaviour, they just allow
third parties to detect it.

A more ambitious design would be to prevent domain servers from being
able to make selective modifications to the data, for example by
having multiple domain servers, and making it difficult for any small
subset of them to identify an area of the database corresponding to a
given domain.  This would restrict domain servers to being able to
corrupt domain data randomly, but not modify specific domain
information in a targetted way.

Designs for a system exhibiting such properties solicited!

Now comments on Bills proposed DNS service:

Bill Stewart writes:
> The protocol is relatively complicated, and unless I'm missing something
> major, you can do a much simpler design with basic public-key signatures,
> as well as supporting alternative architectures for DNS-like services.
> 
> [...server signs domains, providing non-repudiation function...]
> 
> So a tuple for domain.HLD consists of (domain, HLD, seqno, ip, pk,
> sig, cert), where sig is the signature using pk over (domain, HLD,
> seqno, ip) (or perhaps over (domain, HLD, seqno, ip, pk or pkid,
> cert) for completeness.)  (Seqno is a non-decreasing serial number,
> which lets the reader decide which of two conflicting records is
> more current.)

That's quite nice.

> The services that such a protocol needs to provide include
> - letting the domain-name owner verify whether the name is still there
> - letting the public verify whether names appear to be missing

With your protocol, the public needs to mirror all the domains to
definitively verify that information is missing.  With the hashtree
the only data needing independent mirroring is the master hash, the
rest can be obtained from the server, it can not lie without
invalidating the master hash.  Though as you say, with your protocol
you can probably rely on the owner or users of the domain to complain.

> - letting the domain-name owner and maybe the public resolve disputes by
>       demonstrating to the server that the name should be served.

The domain-name owner will typically be less able to distribute the
dispute information than the domain server.  People go to the server
for domain information.  Perhaps one could rely on the domain owner to
email the non-served domains to other servers and have them provide
service, and distribute the evidence.

> But this design also lets the HLD owner obtain a signature
> from the domain name owner authorizing the revocation,
> which is difficult in the hash tree model.

A domain revocation in the hashtree model is just a normal domain
owner signed domain tuple.  set the ip address to 0.0.0.0 or include a
flag or whatever to indicate requested deletion.

One additional problem with either approach arises when the server
wishes to charge for domain service.  The server needs the ability to
stop service due to lack of payment.  The server could falsely claim
non-payment and thus delete the domain.

> One nice thing about this model is that it allows you to separate
> authorization from distribution - you can be the certified owner of
> conspiracy43.eternity.co.uk even though you run Conspiracy 43
> inside an encrypted ipsec pipenet that can't reach .eternity.com.uk,
> or has different IP addresses depending on where in the net you are.

For eternity probably there isn't an IP address because you aren't
serving your own web pages, and aren't accepting TCP/IP connections so
one may as well use an entirely separate lookup system mapping URLs to
domains.

Adam

Reply via email to