On Sun, 2010-12-05 at 21:51 -0800, David Barrett wrote:
> Agreed on it not going anywhere anytime soon. I think they haven't been
> clear on what problem they're trying to solve. If it's to prevent
> government seizures of the domain, I'd suggest that be built into the
> existing DNS infrastructure in a backwards-compatible fashion. Ideally
> this would be part of DNSSec (though I don't think it is) as something like:
>
> 1) When the domain is registered (and renewed), record the new owner's
> public key in a big TXT record.
>
> 2) When the domain's DNS record is changed in any way, sign it with that
> public key. (This means only the owner can actually update the DNS record.)
>
> 3) On the client (or recursive DNS server) side, cache a domain's public
> key (if available) until its registration expires. (The "TTL" for the
> key is independent from the TTL of the record itself.)
I'm not sure here - is the domain's public key distinct from the owner's
public key in this context? 'Cause if they are the same then the
recursive DNS nodes (and clients) can evaluate the validity of order to
change the DNS record. If they're not the same, then where does the
domain's private key live and how does the system deal with compromised
keys?
> 4) When renewing the record, refuse any unsigned change, or change whose
> signature fails.
You should consider key continuity and how the system is affected when a
key is compromised. Someone should be able to report that their private
key has been compromised and that future signatures from it should not
be trusted. Hopefully they should be able to do this without losing
control of their domain. But practically, I don't know if that's a
practical requirement. Losing control of the key then probably means
losing control of the domain.
> 5) (This is the big one) If a domain is signed, when the domain record's
> TTL expires, don't flush the cache -- just attempt to renew. If you
> can't renew, keep the old values. (This one is costly as it means you
> essentially never flush signed domain values from your cache.)
I'm not getting the advantage here. Why is this better than just not
having a TTL in the first place, or than just ignoring it completely?
I think it would be better to have DNS stop working for that domain
immediately when TTL expires (so that the person who can renew will
at least notice that renewal is necessary) but not accept any change
orders or renewals within the next couple of years unless signed by
the same key (so that nobody else can swoop in and impersonate them
with a new registrant at the same domain).
And, yeah, after a couple of years of there being no renewal at a
particular domain, why *NOT* let somebody else register it?
> The goal is to ensure that even if the ICANN, Verisign, your registrar,
> and the USG all conspire against you, your domain still continues to
> function to a large degree.
Okay... ICANN removes your registration from standard DNS and
immediately registers the domain to someone else, probably some
arm of the USG. They are not bound by your rules about requiring
a key-signed change order. The existence of a P2P fallback DNS
system is not relevant if the standard DNS system points at a
domain that's been transferred, because the fallback is never
invoked. Verisign is conscripted to publish a certificate for
the new owner of the site, and the users' browsers will never so
much as pop up a warning that the certificate is changed from last
time you visited this site. How does this P2P DNS fallback
interfere with that?
Bear
_______________________________________________
p2p-hackers mailing list
[email protected]
http://lists.zooko.com/mailman/listinfo/p2p-hackers
