

Bernstein's New Mission Is To Cryptographically Protect Every Internet Packet - tsally
http://cr.yp.to/talks/2009.06.27/slides.pdf

======
tsally
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>

Homepage: <http://cr.yp.to/>

~~~
dtf
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!

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

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

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

------
Bjoern
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...](http://events.ccc.de/congress/2008/Fahrplan/events/2906.en.html)

(links to mp4, mp3, etc.)
[http://events.ccc.de/congress/2008/wiki/Conference_Recording...](http://events.ccc.de/congress/2008/wiki/Conference_Recordings#H.264)

(mp4)
[http://mirrors.dotsrc.org/congress/25C3/video_h264_720x576/2...](http://mirrors.dotsrc.org/congress/25C3/video_h264_720x576/25c3-2906-en-
why_were_we_so_vulnerable_to_the_dns_vulnerability?.mp4)

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.

~~~
illumen
'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.'

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

------
omouse
Is this more secure than Freenet then?

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

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

