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.