Of course. It's just that this is 6-7 orders of magnitude easier than breaking RSA, even against a relatively hard target.

No. It's however hard breaking RSA is plus 6-7 orders of magnitude easier because you still need to break RSA.

Signings shouldn't help the attacker unless your hash is broken... it probably takes a worse break than the current ones against MD5 and SHA1, as well.

That's not true. doi:10.1016/S1007-0214(05)70121-8 for example on weak-key attacks against digital signature systems.

they [the banks] can upgrade much more easily than DNSSEC if RSA-1024 falls.

Sort-of. SSLv2 has been considered obsolete for a long time, but it took new PCI-compliance procedures to really shake it out of a lot of organizations I've worked with.

Upgrading is hard. Saying upgrading HTTPS's RSA-1024 is "easier" than upgrading DNSSEC is patently meaningless: We're not really talking about upgrading, we're talking about replacement.

There are still sites without MX records and still new FTP clients being made. I consider the proponents of DNSSEC and IPV6 similarly incompetent largely because they have spent so little time exploring how to replace our existing crap.

DNSCurve is primarily an exercise in supplanting the existing system; that's what the entire system is built on, *how do we get security*, not how do we build the most secure system, or the best system by any technical measure.

You probably want to avoid them anyway... I'm a grad student so I don't design very practical stuff

Implementations are uninteresting. Where are these identity schemes published?

What the hell are you blathering on about?

As is common for crypto protocols, if the RSA key in HTTPS is broken, a man in the middle can mess with the protocol in real time.

No it can't. You still need a way to get the packets to the man in the middle, and a way to get the packets where they don't belong.

DNS, using UDP, offers no such protection.

Secondly, DNSSEC uses the RSA key for a long time, and clients can get lots of signings to launch offline attacks. This attack doesn't work on HTTPS, which uses RSA to only sign/encrypt a session key. It doesn't work on DNSCurve either.

All other things being equal, that answers mmell's question: Why is RSA safer for bank transactions than for DNSSEC?

How the hell can anyone be as fucking numb as you are to these two very simple things and still "be a cryptographer"?

I call shenanigans! If you're actually paid to design cryptosystems, let me know which ones so I can avoid them.

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.