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.
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.
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.
> 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.
NIST reviews! Official IANA identifiers for TLS! A prove-the-negative patent resolution! And, it'd sure be nice if the NSA came out and endorsed the solution!
Yeah, this is definitely an apples to apples standard compared to what DNSSEC dealt with.
I am, for the record, (a) a proponent of x509 and (in particular) TLS, (b) not a particular fan of "nym security", (c) not optimistic about any ground-up replacement of TCP. It's weird that you're arguing with me about this stuff.
I'm not arguing with you (aren't you just summarizing somebody else's viewpoint?). I think it's important to see the non-technical factors that may cause a new scheme to lose out to even technically-inferior alternatives. How much value is there in a NIST or NSA rubber stamp? Well, so far MS and Mozilla have only implemented Suite B curves. How hurtful is the ECC patent FUD? Well, look at how much work Red Hat did to strip all ECC code from all the software they ship in their products. How likely is it that there will be a standard that takes off without being distributed by either Microsoft or Red Hat (or Oracle or CentOS)? What would it take to get Curve25519 used in Firefox? Well, there's not much reward for implementing a curve that isn't going to be implemented by many other browsers or servers, so it's hard to justify spending time to consider it, even ignoring the NIST/NSA/IETF/IANA angle.
22 comments
[ 0.16 ms ] story [ 69.4 ms ] threadBecause 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.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...
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.
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.
Yeah, this is definitely an apples to apples standard compared to what DNSSEC dealt with.
I am, for the record, (a) a proponent of x509 and (in particular) TLS, (b) not a particular fan of "nym security", (c) not optimistic about any ground-up replacement of TCP. It's weird that you're arguing with me about this stuff.
But he's straight-up right about DNS security.
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.
http://ha.cx/DJB.mp4
How modest.
http://vimeo.com/18279777
It starts roughly 13 minutes before DJB actually begins to speak, and you can't fast forward unfortunately.