Re: djb

On Wed, Jan 5, 2011 at 4:50 PM, Aaron Swartz <me@aaronsw.com> wrote:

> 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.
>

Sure.  But when it comes down to it, that's his only answer for how you
acquire keys, not just IPs.  Anything to avoid the root.


>
> 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
> http://cr.yp.to/talks.html#2003.02.11)
>

You are in denial.  He without question is refusing to endorse using the
root. He's very clear -- "I used to think this was a reasonable model"
"Maybe we should store the keys for TLDs like .com and .de"  "If we're just
willing to use these URLs..."

Heck, he's even got a screenshot of the domain takedown.


>
> 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."
>

You know, I totally respect somebody saying "I don't know".  I really do.
Not enough people say that.

But key management is without question the core problem in "authenticating
and encrypting the Internet".  If you don't know, that's fine, but (if
you'll forgive the slight snark) you should title your talk "I don't know
how to authenticate and encrypt the Internet".

Put another way, if he *knew* who the authority would be, as you imply in
your second point, he wouldn't be saying "I don't know who the authority
should be".


>
> 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.
>

P2P DNS doesn't squick me out, it just doesn't achieve the level of security
or availability we've come to expect from even mere DNS.  All of these
systems fall to Sybil, every last one, because they're fundamentally
designed to allow random parties to show up and start routing people.  To
every feature there is a cost, and the cost in this case is "they might be a
malicious actor, and they might impersonate a hundred thousand malicious
actors".

To DJB's credit, he does not recommend using P2P DNS to resolve the "www"
CNAME to the Nym.  That's pretty transparently insecure.  But you'll notice
he offers nothing else that can do this name to nym translation.  And he
can't -- he's basically talked himself into the precise corner Zooko
predicted.

Look, I know DNSCurve with a centralized root can offer the semantics we
desire.  Frankly, it's a much more interesting technical discussion to
compare two systems, each with their tradeoffs.  And that's ultimately what
I do for most of the piece -- a huge portion of that is "lets analyze
DNSCurve on its merits".

But at the end of the day, if he wants to abandon the component that makes
his system credible, it's neither of our places to make excuses for him.