At 10:03 PM 3/3/99 GMT, Adam Back wrote an interesting proposal on
verifying that domain name servers hadn't had any clients deleted,
using hash trees to verify that everything that had been on the server
was still there.
>I think it would be useful to try to design systems which interface
>with the existing DNS system, but try to be much more resilient to
>political attack than the existing system.
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.
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
- letting the domain-name owner and maybe the public resolve disputes by
demonstrating to the server that the name should be served.
- letting the server obtain permission from the domain-name owner
to stop serving the name.
Define "authority" as the owner of a higher-level domain (HLD)
(e.g. ".to" or ".com"), who has the right to assign domain names inside that HLD.
Let pka be the HLD authority's public key, using Adam's notation,
let pk be the public key of the owner of "domain" inside that HLD.
Let "cert" be a signature using pka over the tuple (pk, domain.HLD)
certifying that Key PK has authority over the name domain.HLD.
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.)
This way, when somebody notices there's a DNS entry missing
from the DNS server run by Authority (e.g. his own),
he can go squawk the certificate and the tuple,
and anybody can go check that the certificate is valid and
ask the server to reinstate it or justify refusal to do so.
Furthermore, the owner can post the tuples (pk, domain.HLD, cert) and
optionally (domain, HLD, seqno, ip, pk, sig, cert),
where popular search engines can find them
This means that people who want to check for names can
search for them, or maintain lists, and check that they're in the server.
It also means that if the server wants to revoke a name,
it's easy to sign the revocation, though admittedly that doesn't
indicate the date of the revocation, though if that's a problem,
the cert could be over the tuple (pk, domain.HLD, seqno) to verify order.
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.
(e.g. revoke=sig(key=pka, domain.HLD, pk, sig(key=pk, pk, domain.HLD, "REVOKE ME")))
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.
>Space should be made within the DNS system for domains which are not
>only declared explicitly first come first served as the .to (Tonga,
>out of a US embassy) domains are, but which are designed to be
>resistant to such attacks should governments make attempts to revoke
>selected domains.
Anybody who can buy a second-level domain can hang a
hash-based or pubkey-based name space underneath;
the only reasons to use a TLD is because it looks cool
so people will remember you, which is nice but optional,
and because it's harder to be revoked if you own your own country.
cocacolarecipe.eternity.co.uk isn't as cool as cocacolarecipe.com
or cocoacolarecipe. or maybe cocacolarecipe.taz, but it'll do.
Thanks!
Bill
Bill Stewart, [EMAIL PROTECTED]
PGP Fingerprint D454 E202 CBC8 40BF 3C85 B884 0ABE 4639
