And I'm not sure what you mean by "breaking TCP"...
Breaking TCP presently requires guessing sequence numbers reliably or a MITM attack. Both are extremely uncommon outside of LANs.
This isn't true... the best known attacks against RSA are just to factor the modulus.
What isn't true? Breaking RSA is easier than breaking RSA and TCP? (note "also" in my original phrasing)
255-bit ECC is probably slower than 1024-bit RSA for verifies, however.
Not just probably, definitely. That's probably why dnscurve uses Curve25519 (very very fast DH), which is significantly faster than RSA at similar key-strengths.
They can get new ciphers rolled out to browsers, and degrade to RSA for browsers that haven't implemented them. These problems are considerably worse for DNS servers and routers.
On the other hand, with DNSSEC, we're talking about using RSA in a new standard; its performance and size are already problematic at the current strength, and will get cubically worse at greater strengths.
Agreed. We already have excellent information about how long it takes to roll out a new protocol (and stop supporting the old protocol): A-fallback for MX records, Path-MTU discovery problems, ECN, and SSLv2 are things that we still have to deal with today, and MX records were introduced over twenty years ago.
It's evident that new protocols need to be carefully designed to be compatible with existing systems, and that the existing systems will be around for a long time. DNSSEC simply isn't compatible with DNS.
So saying "These problems are considerably worse for DNS servers and routers", I believe is woefully understated. These problems are the most important factor here, on a live, moving, Internet.