
Encrypting and authenticating the whole Internet: DJB (video) - wglb
http://27c3.iphoneblog.de/recordings/4295.html
======
tptacek
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.

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

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

But he's straight-up right about DNS security.

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

~~~
tptacek
I think there's zero chance any of this stuff ever gets deployed, for whatever
that's worth. I think that, and that Bernstein is probably right.

------
jolan
Mirror here (tested with VLC - File - Open Network):

<http://ha.cx/DJB.mp4>

~~~
david-sarah
This seems to be 404, can you put it back up? Thanks.

~~~
jolan
I had to move it since my VPS is capped at 5mbps and it was overloaded. Ask
for the link via email (in my profile).

------
requinot59
I can't read the video stream on linux (ubuntu 10.04). Does anyone have a
direct video d/l link or something, please?

~~~
Groxx
I'm pulling it down now. I can't run it either.

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:

    
    
      curl -LO http://27c3.cdn.undsoversum.de/saal1/saal1_umts-000[14880-15817].ts
    

followed by something like this to merge them all: (from
[http://www.misterhowto.com/index.php?category=Computers&...](http://www.misterhowto.com/index.php?category=Computers&subcategory=Video&article=join_with_mencoder)
)

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

------
Nick_C
Online vimeo presentation here:

<http://vimeo.com/18279777>

It starts roughly 13 minutes before DJB actually begins to speak, and you
can't fast forward unfortunately.

------
akira2501
"Maybe some people had pointed out the problem and the fix before.."

How modest.

------
sullrich
Video seems to work fine with Quicktime open network option. Thanks for
posting!

