[tptacek]

Whether or not DNSSEC is ever seriously deployed, downgrade attacks against HTTPS will remain viable. It's easy to see one reason why this is true (DNSSEC only protects the DNS lookup and not the HTTP traffic itself), but there are other downgrade attacks as well. Downgrades are hard to protect against.

Since DNSSEC can't decisively fix HTTPS downgrade, why bother deploying it?

I addressed your ECC point in the followup to my post:

http://sockpuppet.org/stuff/dnssec-qa.html

Adam Langley seems to agree; he said "it won't happen within 10 years".

[nly]

The objective is to leverage DNSSEC to prevent downgrade attacks. Whether or not you are connecting to a host over HTTP or HTTPS you need to query DNS, which makes it an ideal place to introduce a message to clients to tell them what they should be doing. In an ideal world, a DNSSEC enabled recursive resolver, querying a domain name under a DNSSEC-enabled TLD, should not be fooled to downgrade.

[tptacek]

Again: this mitigates (but probably does not decisively solve) one avenue for downgrade attacks. But downgrade attacks against HTTPS would remain possible --- trivial, in fact, without HSTS, which leaves you with the first-contact problem with or without DNSSEC.

So again: what's the point? Compared to HSTS headers, DNSSEC is incredibly expensive.

[nly]

The point is you can have a record in DNS that says "never use HTTP" that protects clients who haven't yet seen HSTS, and you can use a TLSA-like SRV record to protect clients who haven't yet seen HPKP.

Another thing you're missing is that the CA system almost boils down to the integrity of DNS already, since you can get a CA to issue a basic certificate for a domain simply through weak ownership verification (i.e. if someone controls or MITMs your MX records/responses you're fucked).

[tptacek]

Once again: you can foil domain validation with or without DNSSEC by downgrading SMTP.

Why bother with DNSSEC?

You also didn't address my ECC point upthread. Today, APNIC advises DNS administrators not to use the (crappy) P-256 ECDSA DNSSEC supports, because it breaks ~1/3rd of all resolvers. That's for the ECC variant DNSSEC actually "supports".

How exactly would you propose a rollout of Ed25519 (or equivalent) crypto in DNSSEC? Or, where is the flaw in my argument?

[nly]

SMTP can be protected just as easily as HTTP.

Look, I'm not saying DNSSEC is perfect. I don't like it. I just don't see a practical alternative to solving downgrade attacks in the face of such a plethora of crappy Internet protocols.

[tptacek]

So what you're saying is DNSSEC isn't finished yet. They need to standardize some equivalent to HSTS that will actually work with browsers on real-world networks, and also some kind of record that prevents SMTP TLS downgrade.

When they do that, maybe I'll re-evaluate DNSSEC. In the meantime: the more people who deploy DNSSEC, the harder it gets to fix the broken crypto, so we should just stop.