Hacker News Reader

Comment by phicoh | Hacker News Reader

DNS is where the web would have been if browsers basically didn't force websites to support HTTPS.

The reasoning is that DNS is not important enough to go through the trouble of deploying DNSSEC. These days TLS is often cited as the reason DNSSEC is not needed.

At the same time we see a lot of interest in techniques to prevent cache poisoning and other spoofing attacks. Suddenly in those cases DNS is important.

If all DNS client software would drop UDP source port randomization and randomized IDs, then lots of people would be very upset. Because DNS security was more important than claimed.

DNS cookies are also an interesting case. They can stop most cache poisoning attacks. But from the google article, big DNS authoritatives do not deploy them.

View on HN

The key thing to note is that anti-poisoning countermeasures deployed at major authority servers scale to provide value without incurring cost for every (serverside) Internet "user", and DNSSEC doesn't. A lot of these thing seem like (really, are) half-measures, but their cost/benefit ratio is drastically different, which is why they get rolled out so quickly compared to DNSSEC, which is more akin to a forklift upgrade.

There is no quickly in the Google article. It took them ages to roll out 0x20. Cookies are not very well supported. And then the elephant in the room is the connection between the stub resolver and the public DNS resolvers.

The interesting thing is what happens when BGP is used to redirect traffic to DNS servers: https://www.thousandeyes.com/blog/amazon-route-53-dns-and-bg...

Did it take 25 years? That's the baseline. :)

If we didn't have the web, all networking above OSI L4 on all operating systems would have been encrypted by default. A simple set of syscalls and kernel features could have enabled it. But since the web was there, and popularized a solution for secure communications (TLS + HTTP), everyone just jumped on that bandwagon, and built skyscrapers on top of a used books store.

The weird irony is it's the old "worse is better" winning again. HTTP and TLS are fairly bad protocols, in their own ways. But put them together and they're better than whatever else exists. It's just too bad we didn't keep them and ditch the browser.

Can you articulate what you believe is bad about TLS?

Isn't the Linux kernel at least very unhappy with the idea of adding encryption logic inside, especially in a way where they expose this to user space?

Assuming you are talking about IPSEC, that uses a model that is very hard to deploy.

The problem is that applications typically use TCP connections, but IPSEC works at the IP level. Early on, the (BSD socket) kernel API was basically fixed at the IP level instead of associating it with a TCP socket.

So the whole thing became too complex (also for other reasons). So SSL and SSH were created to have simple things that worked.

SSL took many iterations to get any kind of security, so IPSEC had plenty of time to get it right and take over. But as far as I know, there just never happened. It also doesn't help that TLS is trivial to combine with NAT, and for IPSEC that is quite tricky.

Reply on news.ycombinator.com