[tptacek]

1. The roots and TLDs remain RSA-keyed.

2. As recently as months ago, those keys were 1024-bit RSA.

3. If the zones above those Cloudflare manages are RSA, it doesn't matter if Cloudflare's own zones are ECDSA.

4. ECDSA is itself outmoded and dangerous.[1]. Cloudflare has the first significant deployment of curve-based DNS on the Internet, and because of standards group torpor, they're forced to use bad NIST-curve DSA, while the rest of the world has moved on to better curves and deterministic signatures.

5. It takes just a few hours to write a new draft for ED25519. Pretty much the entire browser vendor community agrees that TLS needs a standardized Curve25519; a draft for that was submitted over a year ago, and still hasn't made it out of committee because of bikeshedding. Worse: browsers can enable Curve25519 piecemeal, because TLS is a negotiation protocol. DNS isn't. Because DNSSEC advocates have pushed deployment of broken '90s crypto, it could take close to a decade to get Ed25519 deployable in DNSSEC.

The idea that better DNSSEC crypto is just a standards document away is a pretty good illustration of what has gone wrong with 21+ years of attempted DNSSEC standardization.

There's a better alternative than DNSSEC, and it isn't DNSCurve: it is literally "do nothing". Don't break the Internet. Don't create a massive new deployment of embarrassing old curve crypto. Don't effectively sign keys over to the NSA. Billions of dollars of commerce flow over the Internet every week and none of it, not one bit, is protected by DNS security. DNSSEC isn't useful, it isn't needed, it certainly isn't a priority. It's in this case a way for Cloudflare to make some extra money, and nothing more.

[1]: http://blog.cr.yp.to/20140323-ecdsa.html

[danyork]

tptacek - the root keys will remain RSA-keyed for some time. The root Key Signing Key (KSK) is 2048-bit RSA. The root Zone Signing Keys (ZSKs) that are CHANGED every 3 months (a ZSK key ceremony is in fact happening TODAY) are 1024-bit RSA.

There was strong interest in changing the algorithm when the KSK is rolled (when that occurs is still to be decided), but for the moment an algorithm change will not be part of that.

I don't deny that deployment of ED25519 will take some time. Once approved it has to be integrated into the signing software. It's also got to be integrated into the validation side. It's going to take time. So lets get started!

[tptacek]

How about, instead of getting started, we accept that DNSSEC is a failed 21-year-long experiment, and figure out a better way to get the moral equivalent of HSTS and HPKP for email links?

[galois198]

In the event that DNSSEC is adopted, what would the best course of action be to protect sites?

[tptacek]

The concern I have with DNSSEC is that if it's adopted --- where "adopted" means "by the major email providers and by browsers" --- there's not much you can do to protect yourself from the SIGINT agencies that control the top of the DNS tree.

If there was a significant benefit to users for DNSSEC adoption, I'd be my normal tedious "maybe it's good, maybe it's bad" self. But the benefits aren't there. Instead, DNSSEC will impose immense operational costs and in some ways reduce security:

https://news.ycombinator.com/item?id=10541719

This isn't a hard decision and I don't have a hard time siding with the anti-surveillance crowd on it.