No. We do not rely on DNS now. The whole design of TLS is premised on the notion that the DNS is insecure. Much to NSA's annoyance, if I switch MAIL.GOOGLE.COM in the DNS, I cannot easily MITM people's Gmail sessions.
>Much to NSA's annoyance, if I switch MAIL.GOOGLE.COM in the DNS, I cannot easily MITM people's Gmail sessions.
If the user is using a new browser or has an expired HSTS header, wouldn't it actually be trivial to do? Or are you also relying on TACK to say "never connect to mail.google.com without TLS" or on HTTP/2.0 to mandate TLS everywhere?
My assertion is that absent some way to force TLS from the start on the connection owning DNS allows you to MITM a user that types mail.google.com in the address bar. Where is that wrong?
If you don't distribute the pin along with the browser you don't get TLS forced on the first connection. As you yourself said in the other thread TLS+TACK doesn't solve this either. So this is hardly a fundamental property of TLS.
Browser trust anchors aren't a fundamental property of HTTPS/TLS? That's like saying "TLS is insecure if you don't distribute any root certificates with your browser".
Really? You're arguing that a feature that was first implemented in 2011 is a fundamental property of TLS? And are you also arguing that the whole web should have Google/Firefox/IE/Safari ship a certificate pin with the browser? That will surely scale...
If we're doing that why do we need CA's at all? Just ship pins of self-signed certificates to all the browsers and trust Google with the integrity of the database.
