W3C home > Mailing lists > Public > www-archive@w3.org > January 2011


From: Aaron Swartz <me@aaronsw.com>
Date: Wed, 5 Jan 2011 19:50:58 -0500
Message-ID: <AANLkTi=T_4jFToTRm+20-AkZavhbbOYnARV0dPfpps6p@mail.gmail.com>
To: Dan Kaminsky <dan@doxpara.com>
Cc: www-archive <www-archive@w3.org>
Re: http://twitter.theinfo.org/22811626633699328

I just rewatched the clip you sent. Here is what I understand djb's
position to be:

1. We can adopt the secure and decentralized approach but give up
human readable names. This is the nym solution. It's extreme and
impractical for normal use.

2. We can adopt recursively delegated keys from the root. This is, as
his slide says, the "Standard final step" and the one he's been
endorsing since 2003. (See "God sayeth" in

3. As a result of the seizedservers, there is renewed concern about
trusting the root and work on P2P DNS. Dan tacitly endorses this
because there is no other way to ensure availability. But whoever we
decide to trust in the end, this system will apply. "I don't know what
we're going to end up doing, I don't know who the authority should be,
how we're going to end up splitting the authority over names. I do
know that whatever the authorities are, whatever their keys are, this
is a very easy way to secure the communication with them."

I know P2P DNS squicks you out because it is tough to mint names in a
decentralized way, but you don't need decentralized minting -- see,
Dan is concerned merely with availability. Imagine that when you buy a
.com from VeriSign they give you a signed statement saying "key X has
ownership of Y.com until 2012". Now the issue is that the USG asks
VeriSign to stop publishing this fact. P2P DNS can give you a way of
getting this fact from other servers even when VeriSign has stopped
publishing it. This solves the availability problem without solving
decentralized minting.

But djb isn't endorsing a particular P2P DNS solution here. He's just
saying DNSCurve and CurveCP would be compatible with them.
Received on Thursday, 6 January 2011 00:51:49 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:33:54 UTC