Comment by tzs | Hacker News Reader

Comment by tzs | Hacker News Reader

I've only put maybe 2 seconds of thought into this so it is probably stupid, but why don't we have an alternative that does not require third party certificate authorities?

For example why not allow an organization to have its own self-signed certificate authority, and allow it to publish its self-signed root certificate through DNS, and make browsers accept that root for use with that domain?

I see two objections offhand.

Objection #1. It doesn't provide any validation that the certificates were actually made by the legal entity that they claim to be for. It just shows that whoever made the CA had write access to the domain's DNS records. It can't replace EV certificates or OV certificates.

Retort #1. So? Those sites that need EV of OV certificates can keep using the current approach. But a very large number of sites don't need EV or OV certificates. This can be seen by the success of Let's Encrypt which only issues DV certificates. Even some large sites use DV certificates, such as Amazon.

Objection #2. If someone gets write access to your DNS records they can replace your CA!

Retort #2. So? If someone gets write access to your DNS records they can make Let's Encrypt certificates for your domain.

What have I overlooked?

Downgrade protection. It's very tricky to come up with an alternate root of trust for TLS connections that isn't strippable by middleboxes. Stripping isn't even always intentional: a big part of why DANE failed was that middleboxes reject DNSSEC responses, forcing browsers to fall back to X.509. If you have to have an X.509 WebPKI certificate no matter what, then the alternative root of trust just adds attack surface, and while a tiny subset of nerds with ideological objections to X.509 might be fine with that, it flunks the cost/benefit calculations for the browser developers themselves.

If you want to get more specific about using DNS as an alternate root of trust, there are bigger problems. The X.509 WebPKI has mandatory certificate transparency, so misissuance can be detected. Just as importantly, and relatedly, the browser developers can kill a CA that misissues. They've done so multiple times, and have killed one of the largest CAs over misissuance incidents.

Neither capability exists for a DNS-based PKI, which is deeply problematic given that the DNS PKI is --- de jure --- run by state actors.

> It's very tricky to come up with an alternate root of trust for TLS connections that isn't strippable by middleboxes. Stripping isn't even always intentional: a big part of why DANE failed was that middleboxes reject DNSSEC responses, forcing browsers to fall back to X.509.

Is this because DNS traffic often is not encrypted, so middleboxes can see and meddle with DNS traffic?

It's because DNSSEC records look nothing like typical DNS records --- they're very large --- the same middleboxes can drop things like TXT records too, but those are less crucial for ordinary browser users.

This is called DANE. I don’t know if I missed an implied /s in your message.

You overlooked the need for DNSSEC, so another PKI with his own quirks, and somehow less reliable than CAs.

Reply on news.ycombinator.com