Hacker News Reader

Comment by bawolff | Hacker News Reader

The usual counter-argument for https, is that the eggs are already in that basket since anyone with control of dns can just get a new certificate.

For ssh that doesn't really apply as clearly though.

View on HN

Getting a cert requires someone to either compromise the primary DNS server for the domain, or to compromise DNS in multiple independent locations to serve consistent false answers to the probes. It's true that much of the TLS ecosystem is somewhat bound to DNS being trustworthy, but not to the same extent that SSHFP is.

> or to compromise DNS in multiple independent locations to serve consistent false answers to the probes

Do all CAs implement multi-prespective validation these days? Let's Encrypt implemented that only in 2020 and they believed they were the first ones:

https://letsencrypt.org/2020/02/19/multi-perspective-validat...

That also shows up on Certificate Transparency logs.

People used HTTPS before there were Certificate Transparency logs, so there's no reason why those couldn't be run for DNSSEC too.

https://datatracker.ietf.org/doc/html/draft-zhang-trans-ct-d...

https://www.huque.com/2014/07/30/dnssec-key-trans.html

https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-deleg...

The issue with DANE is that now the DNS becomes a new point of failure, which means higher attention to details, more scrutiny, heavier and more secure processes for the root signing ceremonies that require more activity. It recentralizes everything and makes "failing" easier.

The CA system is just multiple points of failure instead of one. One is better.

No, because if one CA is broken only the certificates it authored are vulnerable. It takes more to break the entire system.

A CA can sign for any site. I'd say a single CA compromise breaks the entire system until it is revoked.

DNS root key compromise breaks the entire system until it is replaced.

Not seeing a huge difference.

There are multiple "root" CAs. CA compromises happen all the time, and it has always been dealt with because the fact that multiple "roots" exists means each one has to be kept in check. It's also possible for you (or more realistically for a company) to have their own CA, with their own certificates for all the sites you need. Not being unique applies pressure on each member to behave correctly because it is possible to get rid of them.

It is not possible to revoke the DNS root, and there are no widely deployed alternatives. The incentive to do the right thing isn't as hard: it's just "good" guys doing the right stuff. If something wrong happens, where will you go ? Nowhere else.

What could possibly happen to the root zone? What is the ”something wrong” which you say could happen? I want to see specifics. The CA system is frequently defended by describing its transparency, and how any bad CA will be discovered thereby. I want to know how a compromised root zone could be used in an actual attack, and how this specific attack is easier than attacking a CA quickly enough before discovery.

So? If an authoritative DNS server operator is broken, only the domains below that operator (in the DNS hierarchy) could be impacted.

DNSSEC relies on a hierarchy of trust, with a single root zone at the top. If the root zone has issues, the whole system breaks down.

In contrast, there is no unique "root CA" that can fail.

If one CA fails, it can still issue certificates for all domains. You can’t avoid any bad CA by using a good CA; any other bad CA can still issue certs for your domains. The CA system as a whole can only ever be as good as its worst CA.

> For ssh that doesn't really apply as clearly though.

Do you think that DNS-based proof of ownership is not something that CAs would use for SSH certification?

Reply on news.ycombinator.com