Bernstein's New Mission Is To Cryptographically Protect Every Internet Packet(cr.yp.to)
cr.yp.to
Bernstein's New Mission Is To Cryptographically Protect Every Internet Packet
http://cr.yp.to/talks/2009.06.27/slides.pdf
21 comments
Though he did recently pay out $1,000 for a hole in djbdns: http://article.gmane.org/gmane.network.djbdns/13864
Still, a pretty impressive track record!
Still, a pretty impressive track record!
His copyright methods are also interesting.
http://thedjbway.org/license_free.html
http://thedjbway.org/license_free.html
djb is also the author of one of my favorite database libraries: http://cr.yp.to/cdb.html
Related discussion from Brad Templeton about why crypto isn't widely used: http://ideas.4brad.com/overengineering-and-non-deployment-ss...
The idea in the paper is not to encrypt every packet, but every DNS packet. Something like a (better) substitute to DNSSEC... Good read.
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.
The question is, though, do we trust the host (IPsec) or the application (application-level crypto)?
It would be great if there were an easy-to-use crypto API that one could just plug into ones apps. Sadly, it is not the case, yet.
It would be great if there were an easy-to-use crypto API that one could just plug into ones apps. Sadly, it is not the case, yet.
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.
(Info) http://events.ccc.de/congress/2008/Fahrplan/events/2906.en.h...
(links to mp4, mp3, etc.) http://events.ccc.de/congress/2008/wiki/Conference_Recording...
(mp4) http://mirrors.dotsrc.org/congress/25C3/video_h264_720x576/2...
So dnscurve is really great, but if we need two or three times the systems to realize it nobody is going to implement it for real usage.
(Info) http://events.ccc.de/congress/2008/Fahrplan/events/2906.en.h...
(links to mp4, mp3, etc.) http://events.ccc.de/congress/2008/wiki/Conference_Recording...
(mp4) http://mirrors.dotsrc.org/congress/25C3/video_h264_720x576/2...
So dnscurve is really great, but if we need two or three times the systems to realize it nobody is going to implement it for real usage.
'Using this software, a low-cost PC with a 2.4GHz Core 2 Quad CPU can encrypt and authenticate 50 billion packets/day to 500 million clients.
The total load on .com is 38 billion packets/day from 5 million clients.'
The total load on .com is 38 billion packets/day from 5 million clients.'
It's certainly more involved than plain ol' utterly insecure DNS--but my impression is that it's orders of magnitude easier and cheaper than DNSSEC.
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!"
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).
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).
FYI, Host Identity Protocol does something similar using ipsec(at least every packet is encrypted), though it provides more features than this.
http://en.wikipedia.org/wiki/Host_Identity_Protocol
Is this more secure than Freenet then?
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?
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.
IPv6 doesn't help, since it doesn't mandate any particular key management (and BTNS isn't even finished), nor does it mandate that IPsec be enabled.
Wikipedia: http://en.wikipedia.org/wiki/Daniel_J._Bernstein
Homepage: http://cr.yp.to/