Google has prepared an update for its Chrome browser that protects users against an attack that decrypts data sent between browsers and many websites protected by the secure sockets layer protocol. The fix, which has already been added to the latest developer version of Chrome, is designed to thwart attacks from BEAST, proof-of …
SSL is due for a complete re-write. Lets go straight to 1024 bit and keep e-commerce secure for a few years.
How bout we don't go for a "fixed for all time" size on the key? How bout we realise that no matter what size we pick it will (at some point in time) become "not enough" and try to come up with an automatic system to adjust it as necessary? Of course the biggest risk here is that the adjustment system is itself targetted and made to scale back to 1-bit (or 0-bits).
SSL vs TLS
SSL v1.0 was never released to the public, SSL v1.1 and v1.2 never existed. I think you mean TLS. There's a really good summary of the history of SSL and TLS on Wikipedia:
TLS 1.0, otherwise known as SSL 3.1, came after SSL 3.0.
"SSL is due for a complete re-write"
I think you're missing the point that TLS has already been re-written twice since the affected version, but it was a waste of time on both occasions because nobody bothered to deploy it.
I think you meant to say "it only affects TLS v1.0 and earlier SSL v3"
TLS v1.1 brought in CBC attack protection.
You are funny, most sites already use 2048 bit.
SSL certificates use 2048 bit keys (at least that's recommended minimum in certificate requests for general use) but the actual SSL/TLS data encryption is still only 256-bit or 128-bit for the major ciphers in use. Take Google.com for example - right now it has 256-bit encryption using AES256-SHA, 168-bit encryption using DES-CBC3-SHA, and all the other ciphers are 128-bit. Certificate key size is not the same as the encryption key size.