For those that don't know, Daniel Bernstein is the author of qmail, which is probably one of the most secure pieces of software ever written (and a mail transfer agent at that!). Around its initial release, Bernstein offered $500 dollars for a verifiable security hole in the software. He has recently raised it to $1000, and it's hasn't been claimed yet.
True but if you look at the DNSCurve website ( http://dnscurve.org/ ) he does state that it "is part of a larger project to encrypt and authenticate all Internet packets."
Encrypting and authenticating all Internet packets by adding application-level crypto to each and every protocol in use seems like a Sisyphean task to me. IPSec is more ambitious because it is lower in the protocol stack, but if you really want to encrypt all the traffic on the Internet, that seems like a more plausible approach to me.
This is great, I like the core idea of solving the internet's "integrity epidemic" from the starting point of being easily deployable and usable (where things like DNNSEC and IPSec fail). This is the only way things will change... His thought at the end: "When we instead design secure, easy-to-use systems, sometimes they turn out to have perfectly acceptable performance!"
Actually Dan Kaminsky commented on DNSCurve and said it to be very clever and interesting but not realizable because it costs too much. Costs in this sense is the requirement of machines to realize this. If you substitute the current DNS infrastructure with DNSCurve you need a lot more systems to handle the current load.
The main issue here is that all other services build upon the "Federation" of DNS. Meaning, e.g. google, microsoft, and all kind of other companies don't trust each other but fundamentally they are connected by DNS which allows all kinds of scary attacks.
Solving the problem with Crypto is cool, SSL Userland Certificates was also such a try but is not going to work because in this case the costs outweigh the benefits. Meaning that the increased crypto will require us to run many more machines to serve current loads of DNS usage.
There are also attempts to build crypto direct into the TCP/IP aehm. ISO OSI model as a more fundamental approach to really encrypt all traffic. If this ever will be realized on a greater scale is doubtful again because people tend to look at the costs/benefit/trouble tradeoff. (in favor of costs).
Freenet fails to deliver on what it promises. Your peers can identify you as the origin of inserts and requests with a high probability. If you use Frost you are particularly vulnerable.
Protecting every single packet on the internet... Isn't this why we have IPSec?
I would also say he misses the mark on why https/SSL is underemployed: Either you have to pay outrageous sums of money for wildcard certificates or you have to have a public IP for every domain you want hosted.
Had https allowed sending host-headers etc before authenticating (like with TLS) this would not have been a problem, but given the current state of IPv4 addressing space and the refusal to support TLS in the https protocol, this is unlikely to change any time soon. At least not before IPv6 goes mainstream. IPv6 which mandates that IPSec must be supported.
I'm not sure I see how this effort is being particularly useful. Am I missing something obvious here?
IPSec probably introduces too much latency for DNS. As far as I know, DNSCurve doesn't add any additional packets to the transfer. One packet request, one packet response. I doubt IPSec works that way.
Wikipedia: http://en.wikipedia.org/wiki/Daniel_J._Bernstein
Homepage: http://cr.yp.to/