4 ms·

Bernstein's New Mission Is To Cryptographically Protect Every Internet Packet

59 points by tsally 17y ago

tsally 17y ago
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. Wikipedia: http://en.wikipedia.org/wiki/Daniel_J._Bernstein http://en.wikipedia.org/wiki/Daniel_J._Bernstein Homepage: http://cr.yp.to/ http://cr.yp.to/
- dtf 17y ago
  Though he did recently pay out $1,000 for a hole in djbdns: http://article.gmane.org/gmane.network.djbdns/13864 http://article.gmane.org/gmane.network.djbdns/13864 Still, a pretty impressive track record!
- bayareaguy 17y ago
  djb is also the author of one of my favorite database libraries: http://cr.yp.to/cdb.html http://cr.yp.to/cdb.html
- Bjoern 17y ago
  His copyright methods are also interesting. http://thedjbway.org/license_free.html http://thedjbway.org/license_free.html
trezor 17y ago
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?
- eggnet 17y ago
  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.
- wmf 17y ago
  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.
wmf 17y ago
Related discussion from Brad Templeton about why crypto isn't widely used: http://ideas.4brad.com/overengineering-and-non-deployment-ssl-tls http://ideas.4brad.com/overengineering-and-non-deployment-ss...
omouse 17y ago
Is this more secure than Freenet then?
- duskwuff 17y ago
  Not a valid comparison. Freenet and DNSCurve perform completely different tasks.
- brl 17y ago
  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.
sucuri2 17y ago
The idea in the paper is not to encrypt every packet, but every DNS packet. Something like a (better) substitute to DNSSEC... Good read.
- timf 17y ago
  True but if you look at the DNSCurve website ( http://dnscurve.org/ http://dnscurve.org/ ) he does state that it "is part of a larger project to encrypt and authenticate all Internet packets."
  - neilc 17y ago
    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.
    - enneff 17y ago
      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.
timf 17y ago
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!"
Bjoern 17y ago
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.html http://events.ccc.de/congress/2008/Fahrplan/events/2906.en.h... (links to mp4, mp3, etc.) http://events.ccc.de/congress/2008/wiki/Conference_Recordings#H.264 http://events.ccc.de/congress/2008/wiki/Conference_Recording... (mp4) http://mirrors.dotsrc.org/congress/25C3/video_h264_720x576/25c3-2906-en-why_were_we_so_vulnerable_to_the_dns_vulnerability?.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.
- khafra 17y ago
  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.
- illumen 17y ago
  '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.'
Bjoern 17y ago
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).
surki 17y ago
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 http://en.wikipedia.org/wiki/Host_Identity_Protocol

59 points by tsally 17y ago

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. Wikipedia: http://en.wikipedia.org/wiki/Daniel_J._Bernstein http://en.wikipedia.org/wiki/Daniel_J._Bernstein Homepage: http://cr.yp.to/ http://cr.yp.to/

dtf 17y ago
Though he did recently pay out $1,000 for a hole in djbdns: http://article.gmane.org/gmane.network.djbdns/13864 http://article.gmane.org/gmane.network.djbdns/13864 Still, a pretty impressive track record!
bayareaguy 17y ago
djb is also the author of one of my favorite database libraries: http://cr.yp.to/cdb.html http://cr.yp.to/cdb.html
Bjoern 17y ago
His copyright methods are also interesting. http://thedjbway.org/license_free.html http://thedjbway.org/license_free.html

trezor 17y ago

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?

eggnet 17y ago
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.
wmf 17y ago
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.

wmf 17y ago

Related discussion from Brad Templeton about why crypto isn't widely used: http://ideas.4brad.com/overengineering-and-non-deployment-ssl-tls http://ideas.4brad.com/overengineering-and-non-deployment-ss...

omouse 17y ago

Is this more secure than Freenet then?

duskwuff 17y ago
Not a valid comparison. Freenet and DNSCurve perform completely different tasks.
brl 17y ago
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.

sucuri2 17y ago

The idea in the paper is not to encrypt every packet, but every DNS packet. Something like a (better) substitute to DNSSEC... Good read.

timf 17y ago
True but if you look at the DNSCurve website ( http://dnscurve.org/ http://dnscurve.org/ ) he does state that it "is part of a larger project to encrypt and authenticate all Internet packets."
- neilc 17y ago
  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.
  - enneff 17y ago
    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.

timf 17y ago

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

Bjoern 17y ago

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.html http://events.ccc.de/congress/2008/Fahrplan/events/2906.en.h... (links to mp4, mp3, etc.) http://events.ccc.de/congress/2008/wiki/Conference_Recordings#H.264 http://events.ccc.de/congress/2008/wiki/Conference_Recording... (mp4) http://mirrors.dotsrc.org/congress/25C3/video_h264_720x576/25c3-2906-en-why_were_we_so_vulnerable_to_the_dns_vulnerability?.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.

khafra 17y ago
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.
illumen 17y ago
'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.'

Bjoern 17y ago

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

surki 17y ago

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 http://en.wikipedia.org/wiki/Host_Identity_Protocol