There is a time in the roll-over where you have published a new key, but the old key is still cached. How does DNSCurve deal with this?
The same way you deal with any change of your NS records.
About new encryption options: Much like HTTP, DNSSEC can be extended by wherever both endpoints support. ... That's how compatibility works in the real world.
Rubbish. Compatibility has never worked that way. My site sees over 30 million messages every month; less than 50% of the senders are RFC2821/RFC2822 compliant. Once a standard becomes entrenched, you must operate on the assumption that it always will be.
Eventually, it becomes irrelevant (like Windows), but it never ever gets replaced.
That's how compatibility works in the Real world.
DNSSEC deployment can be as easy if you like, ... DNSSEC can be plug-in simple also.
DNSSEC is replace your infrastructure simple. It requires replacing hardware and software to deploy. DNSCurve requires supplementing software. A forwarder can run alongside your existing DNS content server requiring no special implementation costs.
DNSSEC isn't designed to fix problems, it's designed to replace DNS.
DNSSEC offers the same level of protection against MITM attacks,
No it doesn't.
The only real wins for DNSCurve are smaller packets today, and router compatibility.
Those are extremely important. DNSSEC doesn't have an Internet-wide migration plan; just a myriad of ideas and best practices. Everyone is assumed to figure it out for themselves.
This has obviously worked very well for IPv6...
Its downsides are poor key management management and future upgrade path,
It has exactly the same upgrade path that DNS has because it's 100% compatible with DNS.
I'll get to the key management in a moment.
and even if the tradeoff was worth it (which I don't believe it is), it's not worth throwing away the momentum DNSSEC currently has.
Says you, one guy, who doesn't operate a very large site, or have very much to change.
You're in fact, a very small and singular member of the Internet. Replacing DNS is an Internet-wide change, and it requires an attention greater than you're willing to give.
That's why your opinion is rejected outright.
We all wish DNSSEC could be simpler, and if DNSCurve was really much easier to deploy for the same security, I'd be all over it. However, I don't believe it is.
Your beliefs don't enter into it. It is simpler to implement, and will be simpler to deploy.
Good deployment tools exist for DNSSEC
No they don't. As I said, DNSSEC deployment requires replacing Hardware and Software. You think this is okay because in your mind the Hardware and the Software is broken. DNSCurve does not.
and many more will be created,
This however, is likely, and I agree. I remember old "MX calculators", and "CIDR calculators": Simple things need a lot of tools, complicated things; doubly so.
but DNSCurve's security downsides in key management can't be automated away.
I don't think they're serious. Keys in X509 and DNSSEC represent organizational processes, but this is a layer of overhead that sites apparently don't need: the reality of how SSL and S/MIME ended up getting deployed demonstrates this thoroughly.
The current existing infrastructure of a single delegation controlled and mandated by the parent is something the DNSSEC key system pretends is shared by the delegate.
It isn't true of course: the parent can unilaterally destroy the delegation and the delegate can't do anything about it.
DNSCurve's key system doesn't pretend otherwise, and so appears significantly less capable than DNSSEC. The idea that I could sign specific records (instead of the right to publish) seems very valuable indeed!
Yet, I don't know of any case where DNS servers were hacked in order to surreptitiously publish evil records. I suppose it could happen, but in any event, it seems valuable to protect against this!
Unless, of course, it comes with the cost of being unable to protect against the attacks that actually do happen.