[agl]

Well, now that DANE is nearly an RFC I should change Chrome to use it rather than the TYPE257 records.

But the important point is that DNSSEC stapled certificates don't need the browser to perform any extra DNS lookups. The certificate itself contains the DNSSEC information and signatures. Since DNSSEC is signed the data can come over any channel; it doesn't have to be port 53.

Unencrypted DNS still leaks the hostname that you're visiting - that's true. However, the destination IP address probably leaks the same information and, if not, we sent the hostname in the clear at the beginning of the TLS handshake! (That's SNI, it allows SSL virtual hosting.)

[sadpluto]

Thanks for answering! What I don't understand is that, given that your starting point is "two computers talking over a malicious network", doesn't the current state of affairs of (unencrypted)DNS mean that it's game over from the outset? That is, if the network is malicious, that MITM could very refer you to an invalid IP address the moment you first try to resolve, say, mail.google.com.

Please don't take this as an argument. I just want to know where I'm wrong! I just can't get over the idea of pushing at the (justifiably) paranoid level for HTTPS while we still have plain-text DNS... even with DNSSEC!

Wish request: Your thoughts on http://news.ycombinator.com/item?id=4268461.

[agl]

Yes, DNS can be used to direct you to the wrong IP address but that hardly matters: an evil network can give you the correct IP address but then intercept all traffic to it.

The key is that the IP address doesn't matter, indeed it shouldn't matter whether the traffic is going over carrier pigeon. You have a name that you wish to connect to, say example.com, and you have some way to send an receive packets. If the other end can prove that they are example.com by means of a certificate then you have a secure connection. How the data gets there and back is immaterial to transport security.