Hacker News Reader

Comment by xurukefi | Hacker News Reader

This is such a nice and pragmatic solution. And yet for some reason people would rather prefer the CA madness we know in the HTTPS ecosystem to be established in the SSH world. I understand that DANE was ahead of its time which is why we settled with CAs for SSL certificates but can we please take a different route this time for SSH?

View on HN

As far as I can tell, DNS-based authentication puts all the trust eggs in the DNS root basket, and then again, in the TLD basket. This seems incredibly brittle and fraught with peril. Am I missing something?

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.

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.

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...

> 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...

> 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?

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.

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.

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.

How do you authenticate the certificate issuing? Public CAs tend to use DNS (either host or dns txt records) to authenticate.

Right now, probably domain validation. But with the TLS infrastructure, if domain validation ends up in disrepute, or if a CA screws around, we can revoke our trust on a subset without needing to replace the system wholesale.

I'm going to skip the long part, but what you're basically requesting is that everyone must trust the countries operating their ccTLDs. Does that sound reasonable? I don't think so.

The long part is well stated here: https://www.youtube.com/watch?v=UawS3_iuHoA

Trusting the country that operates the ccTLD of your website is a much better situation than having to trust all the countries that have CAs operate in them.

A malicious CA in one country can issue a fraudulent certificate for a site in another country, whereas the people operating .ru can't affect the records for example.us so the blast radius is limited by design.

Moreover, no one is required to use a ccTLD, and there are hundreds of gTLDs to choose from, or you could even run one yourself if necessary.

> A malicious CA in one country can issue a fraudulent certificate for a site in another country, whereas the people operating .ru can't affect the records for example.us so the blast radius is limited by design.

Sure and they'll be quickly mistrusted. You can't really revoke DNNSEC trust of an ccTLD operator.

> Moreover, no one is required to use a ccTLD, and there are hundreds of gTLDs to choose from, or you could even run one yourself if necessary.

This is bypassing a dangerous design, at best.

> Sure and they'll be quickly mistrusted. You can't really revoke DNNSEC trust of an ccTLD operator.

But you don't have to, because the blast radius is so much smaller, and the incentives are aligned better. The reason why CAs require such extreme punishment for misbehaviour is that one bad CA can break the trust for every site on the web.

If a country decided to invalidate the security of (predominantly) its own citizens' websites then that wouldn't harm anyone who used any of the other ccTLDs in the world (not to mention the hundreds of gTLDs).

Also, I think you are over-estimating the ease with which a CA can be "quickly mistrusted". What is the record for how quickly a CA has been taken out of browsers' certificate stores, measured from the time of their first misissuance?

And I would argue that revoking CA trust to Let's Encrypt / IdenTrust would be much more disruptive than revoking a single ccTLD operator, since that would mean breaking most sites on the web. So DNSSEC is actually better in terms of the "too big to fail" problem.

> This is bypassing a dangerous design, at best.

But that's my point; DNSSEC lets you bypass the danger of a rogue issuer, by swapping to an alternate domain in the worst case, whereas with CAs you have to hope that the rogue issuer doesn't decide to target you, and wait for the bureaucratic and software update processes to remove that CA from all your users' browsers.

There are definitely limitations to the DNSSEC system as currently deployed, just as there were with the web PKI system before browsers started to patch all the holes in that, but I don't know why my position on this technical question is so controversial. Nevertheless, I really appreciate you taking the time to offer intelligent counter-arguments in your comment, thank you.

> But you don't have to, because the blast radius is so much smaller, and the incentives are aligned better.

Entire countries best case is a small blast radius? A small CA going rogue would have a much smaller one, when we're talking about best case. Worst case is massive either way (say LetsEncrypt and .com). People also buy a lot of domains ignoring the fact that they're ccTLDs. The mere implication that people should choose their domains considering this fact is terrible.

> The reason why CAs require such extreme punishment for misbehaviour is that one bad CA can break the trust for every site on the web.

They can, but it'll be discovered really quick, especially with CAA violations. This can't be said about DNSSEC, any key compromise and abuse is difficult if not impossible to detect. Imagine that but with DANE, indefinite MITM, scary.

> DNSSEC lets you bypass the danger of a rogue issuer, by swapping to an alternate domain in the worst case, whereas with CAs you have to hope that the rogue issuer doesn't decide to target you

That's an insane bypass though. "Just cut your arm off, then it won't hurt." Change your email, figure out how to patch millions of devices out in the wild, so many problems.

A rogue issuer is much less hassle short- and long-term to deal with. Most browsers ship CRLite or similar and can revoke the root quickly. You can resume operation with a new CA rather fast.

DNSSEC is a nice complement to WebPKI and vice versa, but for our all sake, it can't be the only source of trust.

The blast radius of .COM is ~most of the western Internet.

It's interesting that all of your examples reference ccTLDs and gTLDs, and not like, ".com" and ".org".

Don't we already implicitly have that sort of trust at the moment with TLS certs considering that proof of ownership via DNS is quite common? Actually, any domain-based validationi, i.e., also HTTP-01, is going to be flawed if you don't trust the registries.

Kind-of, but not really. Multipath validation exists and you can not trust most (if not all) of DNS during issuance technically. Even if that goes wrong, we have Certificate Transparency to detect misissuance, this doesn't exist with DNSSEC.

Reply on news.ycombinator.com