[hsbauauvhabzb]

In 2020 I scraped fortune top 500 companies for dnssec and found iirc one domain using dnssec.

It certainly feels like the wrong way of solving problems (ramming more into the domain registry always seems like a bad option). Is the technology dead or destined to fail?

Edit: rationale: dnssec solves domain validity, but https tls solves almost the same problem but has better backing (azure said they don’t support dnssec and recommended tls as a better alternative). Dnssec also does not solve bgp hijacking, which combined with ip based tls signing servers moots any value dnssec has - sure you could registrar lock your domain via dns (preventing letsencrypt signing things), but if a threat actor has the capability to bgp hijack to perform such an attack and is targeting you, you probably have bigger issues elsewhere.

[teddyh]

When criticizing DNSSEC, you can’t assume that the system for TLS certificates – i.e. CAs – is perfect. They both have their weak points and drawbacks.

Both BGP and certificate issuance have bootstrapping problems, which are handled today by imperfect TOFU-like solutions. DNSSEC is, IMHO, perfectly positioned to solve both of those problems. I.e. use certificates all you like, but verify them by looking up the TLSA record in the DNS using DNSSEC. No need to trust CAs. BGP could possibly use the same solution, using the reverse lookup .arpa DNS space.

DNSSEC is the building block from which secure certificates and BGP routes can be built, without the ad-hoc CA system we have today.

[tptacek]

People say this all the time, but of course the WebPKI has Certificate Transparency, requiring every issuer to register every certificate issued in a globally monitored tamper-proof log, and DNSSEC doesn't. Moreover, the WebPKI got CT because the browser root programs were able to force the CAs to join it. They have no such influence over DNS registrars, many of which are de jure controlled by world governments and will never consent to transparency logging. This very much includes the US, which actively manipulates the DNS for policy ends.

If Comodo knowingly misissues a Google Mail certificate, Google will nuke them from orbit, as it has done in the past with other major CAs. Google can't do anything about .COM mis-signatures.

Thankfully, practically none of .COM is signed.

[belorn]

If the issue is the lack of certificate transparency, then add that as a new standard to dnssec.

Certificate Transparency came into the picture around 2013, by which time https was fairly old. Public resolvers like google, quad 9, and cloudflare could create Certificate Transparency for dnssec today if there was a demand for it.

[tptacek]

I've explained several times on this thread already why DNSSEC won't ever get transparency logging.

[belorn]

You said that registrars won't implement transparency logging, but certificate transparency was not created by certificate authoritative. Google added it to chrome, and they could just as easy add it to their own public resolver.

[tptacek]

And then what happens? Google stops resolving .COM names? I don't think you've thought this through all the way.

[nickf]

I am 100% not arguing with any of your points, you and I agree absolutely on DNSSEC. However...Comodo don't issue anything anymore - it's Sectigo now. Nitpicky, I know!

[theamk]

DNSSEC scares me. CAs are not perferct but they at least have some measure of accountability. Therr are many stories of CAs being removed from browsers, and many of them ended up ceasing operations whatsoever. The reason for that is CAs are interchangeable, if one goes back I can switch to other with almost no distruption.

Compare to DNSSEC which are designed to have single supplier. If a TLD registrar goes bad, what is going to happen? Moving to a new TLD is a huge deal, and affects everyone, including your customer. And browsers can't really ban an entire TLD like they ban CAs.

So yes, both CAs and DNSSEC have some problems. But one of them is pretty good and getting better the time (deprecation of old crypto, short-expiration certificates) while the other is stuck with ancient crypto, constant technical outages, and no chance of improvement.

[tialaramex]

The TLD registrar has enormous impact on you regardless of DNSSEC, and people just seem to put up with it, much as they put up with having an awful US state government, or a terrible HOA, or dozens of other problems.

For ccTLDs you could hope, especially if you are a citizen of the country encoded and it's a democracy, that you can vote for governments who require the TLD registrar to meet your needs. Will that work? Well, no worse than them ensuring adequate drinking water and that sort of thing.

TLDs seem primarily to be chosen for existing popularity, so no matter how badly COM is run, people will insist they want a .com domain, and then complain about how badly the TLD is run. I don't see DNSSEC ever making that substantially worse.

Suppose you paid $50 last year for theamk.example - what sort of abuses could the example TLD already do - ignoring DNSSEC entirely ?

Somebody has decided to register the\u{0251}mk.example, the\u{0431}mk.example and now the\u{ff41}mk.example - your TLD's policies say that they take this sort of thing "very seriously" and they try to ensure that after they've been paid in full for the domains they get around to removing these bogus sites used to attack your customers just as soon as you file the necessary paperwork, plus 90 days admin.

They might tell you that somebody else offered them $5000 for theamk.example and so too bad now it's not yours any more. Can you fight them? Yeah, and eventually you might even win, but meanwhile your domain isn't working. I hope you didn't need that.

Oops due to an "error" theamk.example just doesn't resolve any more. Don't worry though, they aim to fix such errors within 45 days. Or you can pay for $25 Expedited Support ?

Oh no, apparently "Theamk Inc." in Beijing says you are squatting on their rightful trademark which they registered last week in Bulgaria apparently. The TLD registrar has decided to immediately transfer your domain to them.

[theamk]

The important stuff is not just websites I host, but also websites I visit. And in all the scenarios you mention, I (and everyone else) would know that it happened very clearly, as it is basically denial of service attack. Even if this is a takeover event with almost-instantaneous replacement with the phishing page, the website owner would detect this and if the website is at least a bit popular, the news would definitely hit the HN top page :)

For an example, sr.ht is hosted by Haitian TLD but has Let's Encrypt CA. Thanks to CT logs, I trust that the connections are secure, and when I download software from it I am getting it from the rightful place. (Or not getting this at all because website is down. That's a nature of the web, things break)

But with DNSSEC? No assurances at all. Owner of .ha can be coerced or bribed by $(your least favorite nation) and this may never be detected, especially if this is a targeted attack to specific addresses. And even if detected, there will _still_ be people saying, "hopefully this does not affect me, I won't move domains and risk my search traffic".

And that's the reason that DNSSEC scares me and WebPKI does not.

[tialaramex]

Web PKI CAs aren't psychic, they just use DNS. So your claim ends up being that you believe DNS answers from the DNS can be tampered with by parties who control those answers (which includes the TLD registrar, this part checks out), but, somehow every Web PKI CA would know if this happened and disregard the results.

Not only is your claim obviously not true in principle, we know it's not true in practice, disrupted DNS causes real issuances which are let's say... suspicious. They're not mis-issuance under current policy because the Web PKI trusts the DNS, but they would trigger exactly the scenario you believe can't happen.

[nickf]

You're right of course, but there's progress being made to require multi-perspective verification (do DNS lookups from many different and ideally randomised locations, only issue if you get consensus). It's not perfect, but it's a great step in the right direction.

[yencabulator]

DNSSEC can be tampered without leaving a trail of evidence. If you MitM DNS for all the outbound IPs a CA uses, the end result of that gets logged in Certificate Transparency. And since 1) sites can and do monitor CT for their domains and 2) browsers demand the certificate has been submitted to CT, we know that e.g. google.com is not MitM'ed.

[tialaramex]

BGP has its own PKI, the RPKI, so it doesn't need to lean on DNS whereas much of the other Internet systems already leans on DNS so might as well choose DNSSEC.

As with any PKI, the RPKI isn't effective if you don't use it, or if you use it in a merely advisory capacity and then routinely ignore its advice. And as with DNSSEC of course if you actually use this technology and people screw up (which will happen) there are outages, which would not have happened if you used no security technology.

In addition though, RPKI signifies business arrangements and so you can imagine real world policies may vary slightly from what RPKI says. For example, suppose you're a Canadian ISP and Big US ISP A says they're not going to use Long Haul provider X any more from Thursday. Sure enough the RPKI entries for ISP A via provider X expire after Wednesday. As of 00:05 on Thursday, 40% of routes for ISP A on your systems transit provider X. Should you kill those? Your customers would perhaps be pretty angry if the ISP A CEO later clarifies that "obviously" they meant from start of Business Hours. How about at 12:00 midday? How about the Monday after ? What if two months after this announcement, having left these routes in place you discover provider X were hijacking ISP A traffic and this was never merely a mistake, it was leverage ?

[belorn]

DNSSEC does actually have protection against bgp hijacking. The dnssec root key are (generally?) hardcoded into the resolvers, so even if someone would do a bgp hijacking of the root servers they would still not resolve.

[tptacek]

Who cares? If you control BGP, you control the meaning of the IP addresses DNS resolves to.

[belorn]

If the attacker bgp hijacks the record target they need to also bgp hijack the authoritative server that holds the TLSA record (which the client could verify during an attack).

If the attacker want to bgp hijack the authoritative server they will need to bgp hijack the TLD name servers that holds the DS posts for the authoritative server.

If the attacker want to bgp hijack the TLD name servers they will need to bgp hijack the root server that holds the DS posts for the TLD name servers. This they can't do because the root servers keys are hard coded into revolvers.

[tptacek]

None of this matters. An attacker who controls BGP controls IP routing. They can defeat ACME.

[belorn]

TLSA record can specify what specific hash the certificate must have (DANE-EE). You can't solve that with BGP and ACME. The certificate that you get from acme will have a different hash.

With CAA records you can also lock it down to a specific user and method (RFC 8657). How will you solve that with BGP using acme?

[hsbauauvhabzb]

You’re also relying on the client validating DNSSec. I have no idea if/how/when this occurs, or if you can choose to ignore it.

[wlonkly]

A nit, but the resolver, not the client, validates DNSSEC. The client/stub resolver trusts its local resolver. That always struck me as weird.

[bawolff]

> Dnssec also does not solve bgp hijacking

This seems like a pretty unreasonable complaint. Dnssec also doesn't stop phishing. Or nukes.

[technion]

Where it's a complaint worth making is that every time there's a BGP Hijack there are a series of articles written incorrectly claiming DNSSEC would have prevented it.

[hsbauauvhabzb]

What does dnssec solve then?

[bawolff]

Authenticity of dns records. Making sure that the dns record points to the correct ip address.

Whether or not an ip address goes to the correct computer is totally unrelated to DNS, so i'm not sure why anyone would think that has anything to do with a dns security measure.

The relavant security thing for bgp is called rpki.