[nly]

Neither HPKP nor HSTS deal with the issue of a-man-in-the-middle doing a downgrade attack against clients who are visiting a site for the very first time (which can be encouraged through phishing). There are only three ways to deal with this that I can think of:

1) Deprecate insecure HTTP. Literally get all the browsers to agree on a deadline X years out and then drop support for it entirely. HSTS would become irrelevant. I hold little hope of this ever happening, even in a HTTP/2 world. See IPv6

2) Keep increasing the size of the trusted, preloaded list of HTTPS enabled sites shipping with browsers: Neither the implementation nor the process to manage the list scales. It's just crappy all-round.

3) Standardise some SRV records for web protocols in the DNS so browsers can efficiently determine what is supported: Requires DNSSEC to prevent downgrade attacks.

Of these, #3 seems to me to be most practical. With regard to DNSSEC issues I would give these counterpoints:

* DNSSEC could and should be augmented to support ECC, obliterating the concerns with regard to large records and weak RSA key lengths.

* Browsers (or your OS's dnscache process) can cache DNS responses from most of the chain. If the ZSK hasn't been rolled over for a particular domain then I don't see the need to reverify it again on each request. It's not like revocation really works in HTTPS today anyway, so you probably aren't going to bother to check upstream for NSEC records on each request. Or just recheck upstream once a day. I don't really know, but I'm sure these latency issues can be minimized. Googles obsession with latency is how we ended up with the barf that is HTTP/2 rather than something that actually improves websec in the first place.

Another thing I don't often see people mention about HSKP and HSTS, regardless of whether they can be used as "supercookies", is that they create a more-or-less permanent shadow browser history on your machine. This alone is borderline show-stopper afaiac

[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.

[userbinator]

4) Ask sites to publish via an out-of-band channel their certificate fingerprints in an easy-to-verify manner.

I think the centralised CA model really needs to be replaced, although it will be hard to displace as long as those involved have a financial interest in continuing it.

[nly]

The problem you're describing has been donned Zooko's triangle. It's unclear whether decentralised solutions to authenticated human-meaningful names can ever scale to something as large as the DNS.

https://en.wikipedia.org/wiki/Zooko%27s_triangle

[gsnedders]

3) merely requires you can authenticate the DNS response, if I'm not mistaken; DNSCurve would work just as well there as a result.

[nly]

While adoption of DNSCurve would of course be wonderful for privacy online, it cannot be used right now to provide DNS record authentication. The root and TLD nameservers would need to enable support for it, otherwise you'll always be able to MITM the upstream NS record response and redirect all further queries to your own server. Given the politics involved in DNSSEC, and the current anti-crypto climate, I'd say the chances of a fully-chained DNScurve deployment ever happening are about absolute zero.

[rakoo]

No, DNSCurve doesn't authenticate DNS records, it only secures integrity and privacy of your requests (and the responses). DNSCurve and DNSSec don't solve the same problem, they're actually complementary.