This is a great talk; Bernstein is a surprisingly excellent public speaker with solid timing.
You can get most of the points he raises from the foils of previous talks on his website, but, the high points:
* DNSSEC offers DDoS attackers 30+ : 1 amplification for attack traffic; at reasonably low deployment levels, it allows a 200> node botnet to saturate most websites on the Internet. It does this while not actually securing end-user DNS queries, which themselves (his point, not mine) aren't what users need secured.
* Prior attempts to secure the Internet with crypto protocols have failed in predictable ways, ranging from TCPcrypt's "try to encrypt without authenticating" to DNSSEC's "try to authenticate without encrypting" to everything's "try to secure the Internet with stuff that takes a million lines of code just to express the crypto in" to "standardize protocols with crypto mechanisms that real cryptographers have declared off limits over a decade earlier".
* Your conception of the speed of public-key crypto is warped by how slow SSL is; 256 bit elliptic curve crypto, which hasn't degraded in security for almost 25 years, is so fast that you can rekey 10 million sessions every 10 minutes on standard PC hardware.
* That being the case, there's no excuse not to bake fast modern crypto into HTTP so that it's simply always there; Bernstein has created a TCP-friendly alternate transport protocol that does exactly this.
* It's a bad idea to have individual trusted roots, whether they're SSL CA's or DNS roots. Instead, bake public keys directly into URLs or hostnames ("nym-based security"), use CNAMEs and aliases to make things more user-friendly, and secure the end-user connections to the DNS instead of trying to sign every DNS record.
> Your conception of the speed of public-key crypto is warped by how slow SSL is; 256 bit elliptic curve crypto, which hasn't degraded in security for almost 25 years, is so fast that you can rekey 10 million sessions every 10 minutes on standard PC hardware.
This argument implies ECC and SSL are mutually exclusive when they aren't. ECC has been a standardized part of SSL for years and there are many shipping implementations. The same thing stopping ECC in SSL from being deployed is what would stop DJB's ECC-hard-coded protocol from being deployed.
I guess DJB still wants to use Curve25519, but nobody has taken any steps to make Curve25519 actually implementable by mainstream software vendors. The first necessary step is to get it approved by NIST. A second necessary step would be to get IANA identifiers reserved for its use in TLS and other protocols. The third necessary step would be for his claims about the un-patented-ness of the curves verified in a way that venders can rely on. A nice fourth step would be to have it endorsed by the NSA like the Suite B curves. IIRC, this would require some standards to slightly weaken their minimum requirements of 256-bit curves to allow this not-quite-256-bit curve.
> * That being the case, there's no excuse not to bake fast modern crypto into HTTP so that it's simply always there; Bernstein has created a TCP-friendly alternate transport protocol that does exactly this.
Lots of people are working on doing this using existing standards like DNSSEC, TLS, and (maybe) X.509 already. Minimal extensions of these existing standards are going to win unless they are shown to be unworkable or unless some other protocol is soon shown to be obviously overwhelmingly better.
> [B]ake public keys directly into URLs or hostnames ("nym-based security"), use CNAMEs and aliases to make things more user-friendly, and secure the end-user connections to the DNS.
I wonder how this would work in the real world when keys are rotated and/or revoked.
Has DJB written any documentation on his "TCP-friendly alternate transport protocol" that you mentioned above? A quick troll through cr.yp.to didn't reveal anything that matched.
Because I found it interesting, and as an explanation of why I can offer no link: It's in an m3u8 file (UTF-8 m3u playlist). Which links to other playlists, apparently by bandwidth. So I grabbed the largest, and found 938 .ts links. So I'm pulling them, grabbing mplayer (not sure how I was missing it...), and I'll upload the merged result when it all finishes :)
edit: or, if you're adventurous, and can queue up just shy of 1000 videos to play nigh-seamlessly (or want to do it yourself). This should be the high quality set:
//edit: doesn't work for me (jumpy video & audio in result), but YMMV and it's a start:
mencoder -oac copy -ovc copy -idx -o output.ts $(ls *.ts)
//probably needs to be streamed in somehow... Hmmmm.... been too long since I fought with mencoder, I've forgotten most of it :\
edit2: crud, none of the binaries are working properly for me. Gotta compile from source, which'll take far too long for me to do tonight, sorry! The above `curl` is about the best I can do for you right now.
The site's using Live HTTP Streaming -- the video is chunked up, rather than a single file to download. http://27c3.iphoneblog.de/recordings/4295/adaptive.m3u8 is the playlist file. You should be able to open it in VLC to watch.
[+] [-] tptacek|15 years ago|reply
You can get most of the points he raises from the foils of previous talks on his website, but, the high points:
* DNSSEC offers DDoS attackers 30+ : 1 amplification for attack traffic; at reasonably low deployment levels, it allows a 200> node botnet to saturate most websites on the Internet. It does this while not actually securing end-user DNS queries, which themselves (his point, not mine) aren't what users need secured.
* Prior attempts to secure the Internet with crypto protocols have failed in predictable ways, ranging from TCPcrypt's "try to encrypt without authenticating" to DNSSEC's "try to authenticate without encrypting" to everything's "try to secure the Internet with stuff that takes a million lines of code just to express the crypto in" to "standardize protocols with crypto mechanisms that real cryptographers have declared off limits over a decade earlier".
* Your conception of the speed of public-key crypto is warped by how slow SSL is; 256 bit elliptic curve crypto, which hasn't degraded in security for almost 25 years, is so fast that you can rekey 10 million sessions every 10 minutes on standard PC hardware.
* That being the case, there's no excuse not to bake fast modern crypto into HTTP so that it's simply always there; Bernstein has created a TCP-friendly alternate transport protocol that does exactly this.
* It's a bad idea to have individual trusted roots, whether they're SSL CA's or DNS roots. Instead, bake public keys directly into URLs or hostnames ("nym-based security"), use CNAMEs and aliases to make things more user-friendly, and secure the end-user connections to the DNS instead of trying to sign every DNS record.
[+] [-] psykotic|15 years ago|reply
If you haven't seen him speak before, you might enjoy these old MSRI videos:
Fast Multiplication - http://angelina.msri.org/IA/TalkDetail?field_tid=11002
Protecting Communications Against Forgery - http://angelina.msri.org/IA/TalkDetail?field_tid=11479
Not as dynamic as his CCC talk, but educational.
[+] [-] briansmith|15 years ago|reply
This argument implies ECC and SSL are mutually exclusive when they aren't. ECC has been a standardized part of SSL for years and there are many shipping implementations. The same thing stopping ECC in SSL from being deployed is what would stop DJB's ECC-hard-coded protocol from being deployed.
I guess DJB still wants to use Curve25519, but nobody has taken any steps to make Curve25519 actually implementable by mainstream software vendors. The first necessary step is to get it approved by NIST. A second necessary step would be to get IANA identifiers reserved for its use in TLS and other protocols. The third necessary step would be for his claims about the un-patented-ness of the curves verified in a way that venders can rely on. A nice fourth step would be to have it endorsed by the NSA like the Suite B curves. IIRC, this would require some standards to slightly weaken their minimum requirements of 256-bit curves to allow this not-quite-256-bit curve.
> * That being the case, there's no excuse not to bake fast modern crypto into HTTP so that it's simply always there; Bernstein has created a TCP-friendly alternate transport protocol that does exactly this.
Lots of people are working on doing this using existing standards like DNSSEC, TLS, and (maybe) X.509 already. Minimal extensions of these existing standards are going to win unless they are shown to be unworkable or unless some other protocol is soon shown to be obviously overwhelmingly better.
> [B]ake public keys directly into URLs or hostnames ("nym-based security"), use CNAMEs and aliases to make things more user-friendly, and secure the end-user connections to the DNS.
I wonder how this would work in the real world when keys are rotated and/or revoked.
[+] [-] jemfinch|15 years ago|reply
[+] [-] jolan|15 years ago|reply
http://ha.cx/DJB.mp4
[+] [-] requinot59|15 years ago|reply
[+] [-] david-sarah|15 years ago|reply
[+] [-] requinot59|15 years ago|reply
[+] [-] Groxx|15 years ago|reply
Because I found it interesting, and as an explanation of why I can offer no link: It's in an m3u8 file (UTF-8 m3u playlist). Which links to other playlists, apparently by bandwidth. So I grabbed the largest, and found 938 .ts links. So I'm pulling them, grabbing mplayer (not sure how I was missing it...), and I'll upload the merged result when it all finishes :)
edit: or, if you're adventurous, and can queue up just shy of 1000 videos to play nigh-seamlessly (or want to do it yourself). This should be the high quality set:
followed by something like this to merge them all: (from http://www.misterhowto.com/index.php?category=Computers&... ) edit2: crud, none of the binaries are working properly for me. Gotta compile from source, which'll take far too long for me to do tonight, sorry! The above `curl` is about the best I can do for you right now.[+] [-] gnosis|15 years ago|reply
http://27c3.iphoneblog.de/recordings/4295/adaptive.m3u8
(that's from looking in the source from the web page).
That file contains four links:
http://27c3.iphoneblog.de/recordings/4295/hsdpa.m3u8
http://27c3.iphoneblog.de/recordings/4295/umts.m3u8
http://27c3.iphoneblog.de/recordings/4295/edge2.m3u8
http://27c3.iphoneblog.de/recordings/4295/gprs.m3u8
If you run "mplayer -playlist" on each of those, you should be able to see parts of the video.
Unfortunately, on my system mplayer quits after playing just a brief segment and then restarts on the next segment, then quits and restarts, etc..
Perhaps someone else can do better...
[+] [-] Zev|15 years ago|reply
[+] [-] unknown|15 years ago|reply
[deleted]
[+] [-] requinot59|15 years ago|reply
[+] [-] Nick_C|15 years ago|reply
http://vimeo.com/18279777
It starts roughly 13 minutes before DJB actually begins to speak, and you can't fast forward unfortunately.
[+] [-] akira2501|15 years ago|reply
How modest.
[+] [-] sullrich|15 years ago|reply