Remix.run Logo
Remix clone Hacker News
new | show | ask | jobsGithub
▲ cyberax 7 hours ago

> DNSSEC mistakes take your entire domain off the Internet, as if it had never existed.

DNS mistakes take your entire domain off the Internet, as if it had never existed.

I'm preparing a proposal to add an advisory mode for DNSSEC. This will solve a lot of operational issues with its deployment. Enabling it will not have to be a leap of faith anymore.

▲tptacek 7 hours ago | parent [-]

I haven't had to edit the DNS zones for most of my domains in many years. DNSSEC adds an expiring, rotating key change regime to it. If you screw it up, the screwup is cached everywhere, and the failure mode isn't like HTTPS, where you get an annoying popup: you just get NXDOMAIN, as if your domain never existed.

This isn't so much as a scary story I'm telling so much as it is an empirically observable fact; it's happened many times, to very important domains, over the last several years.

▲gzread an hour ago | parent | next [-]

You don't have to expire your DNSSEC keys. You have the option to, or not to. DNSSEC seems extremely flexible about how you manage your keys.

▲daneel_w 5 hours ago | parent | prev | next [-]

I run DNSSEC (to facilitate DANE) and with regards to DNSSEC I haven't had to manually edit my zones in years either. Unlike yourself I don't consider DNSSEC deployment or ZSK rotation / KSK roll-over scary or complex, and seeing an adept technician dole out warnings on the level of "don't run with scissors" is pretty peculiar.

▲indolering 4 hours ago | parent [-]

HTTPS also has expiring keys that also need to be rotated. Most people outsource this to a service provider for them - as is the case with DNS. It's weird how people gripe about standard cryptography/PKI when it comes to DNSSEC but not HTTPS.

▲cyberax 6 hours ago | parent | prev [-]

Your objections basically boil down to: DNS is dangerous, and DNSSEC _is_ DNS. This is fair, but the conclusion for me is that we need to make _DNS_ more reliable. Not to keep treating it as a fragile Ming Dynasty vase.

In particular, the long TTL of DNS records itself is a historic artifact and should be phased out. There's absolutely no reason to keep it above ~15 minutes for the leaf zones. The overhead of doing additional DNS lookups is completely negligible.

> This isn't so much as a scary story I'm telling so much as it is an empirically observable fact; it's happened many times, to very important domains, over the last several years.

So has the TLS cert expiration. And while you can (usually) click through it in browsers, it's not the case for mobile apps or for IoT/embedded devices. Or even for JS-rich webapps that use XMLHttpRequest/fetch.

And we keep making Internet more fragile with the ".well-known" subtrees that are served over TLS. It's also now trivial for me to get a certificate for most domains if I can MITM their network.

Edit: BTW, what is exactly _expiring_ in DNSSEC? I've been using the same private key on my HSM for DNSSEC signing for the last decade. You also can set up signing once, and then never touch it.

▲tptacek 6 hours ago | parent [-]

This drills into the core problem: technologists like you look at DNSSEC and say "there is a problem, something must be done, this is something". But it's not enough to identify a problem and solution. The solution has to be worth the cost. Rollout can't be more costly than the original problem.

There's ample evidence that the cost/benefit math simply doesn't work out for DNSSEC.

You can design new DNSSECs with different cost profiles. I think a problem you'll run into is that the cost of the problem it solves is very low, so you won't have much headroom to maneuver in. But I'm not reflexively against ground-up retakes on DNSSEC.

Where you'll see viscerally negative takes from me is on attempts to take the current gravely flawed design --- offline signers+authenticated denial --- as a basis for those new solutions. The DNSSEC we're working with now has failed in the marketplace. In fact, it's failed more comprehensively than any IETF technology ever attempted: DNSSEC dates back into the early-mid 1990s. It's long past time to cut bait.

▲ekr____ 6 hours ago | parent | next [-]

> In fact, it's failed more comprehensively than any IETF technology ever attempted

Now here is where I disagree. Just off the top of my head, how about HIP, IP multicast and PEM?

▲tptacek 6 hours ago | parent [-]

PEM actually gets used? People depend on it? It hasn't been a market success, but if the root keys for DNSSEC ended up on Pastebin this evening, almost nobody would need to be paged, and you can't say that about PEM.

Multicast gets used (I think unwisely) in campus/datacenter scenarios. Interdomain multicast was a total failure, but interdomain multicast is more recent than DNSSEC.

HIP is mid-aughts, isn't it?

▲ekr____ 6 hours ago | parent [-]

Fair enough on Multicast and HIP. I'm less sure about the case for PEM.

S-HTTP was a bigger failure in absolute terms (I should know!) but it was eventually published as Experimental and the IETF never really pushed it, so I don't think you could argue it was a bigger failure overall.

▲tptacek 6 hours ago | parent [-]

There really has been a 30+ year full-court press to make DNSSEC happen, including high-effort coordination with both operators and developers. I think the only comparable effort might be IPv6. But IPv6 is succeeding (slowly), and DNSSEC seems to have finally failed.

(I hate to IETFsplain anything to you so think of this as me baiting you into correcting me.)

▲ekr____ 6 hours ago | parent [-]

Oh, I was basically agreeing with you.

To really nerd out about it, it seems to me there are two metrics.

1. How much it failed (i.e., how low adoption was). 2. How much effort the IETF and others put into selling it.

From that perspective, I think DNSSEC is the clear winner. There are other IETF protocols that have less usage, but none that have had anywhere near the amount of thrust applied as DNSSEC.

▲cyberax 6 hours ago | parent | prev [-]

> There's ample evidence that the cost/benefit math simply doesn't work out for DNSSEC.

Why? What is the real difference between DNSSEC and HTTPS?

I'd argue that the only difference is that browser vendors care about protecting against MITM on the client side. They're fine with MITM on the server side or with (potentially state-sponsored) BGP prefix hijacks. And I'm not fine with that personally.

> Where you'll see viscerally negative takes from me is on attempts to take the current gravely flawed design --- offline signers+authenticated denial --- as a basis for those new solutions.

Yes, I agree with that. In particular, NSEC3 was a huge mistake, along with the complexity it added.

I think that we should have stuck with NSEC for the cases where enumeration is OK or with a "black lies"-like approach and online signing. It's also ironic because now many companies proactively publish all their internal names in the CT logs, so attackers don't even need to interact with the target's DNS to find out all its internal names.

> In fact, it's failed more comprehensively than any IETF technology ever attempted: DNSSEC dates back into the early-mid 1990s. It's long past time to cut bait.

I would say that IPv6 failed even more. It's also unfair to say that DNSSEC dates back to the 90-s, the root zone was signed only in 2008.

The good news is that DNSSEC can be improved a lot by just deprecating bad practices. And this will improve DNS robustness in general, regardless of DNSSEC use.

▲ekr____ 6 hours ago | parent | next [-]

> I'd argue that the only difference is that browser vendors care about protecting against MITM on the client side. They're fine with MITM on the server side or with (potentially state-sponsored) BGP prefix hijacks. And I'm not fine with that personally.

Speaking as someone who was formerly responsible for deciding what a browser vendor cared about in this area, I don't think this is quite accurate. What browser vendors care about is that the traffic is securely conveyed to and from the server that the origin wanted it to be conveyed to. So yes, they definitely do care about active attack between the client and the server, but that's not the only thing.

To take the two examples you cite, they do care about BGP prefix hijacks. It's not generally the browser's job to do something about it directly, but in general misissuance of all stripes is one of the motivations for Certificate Transparency, and of course the BRs now require multi-perspective validation.

I'm not sure precisely what you mean by "MITM on the server side". Perhaps you're referring to CDNs which TLS terminate and then connect to the origin? If so, you're right that browser vendors aren't trying to stop this, because it's not the business of the browser how the origin organizes its infrastructure. I would note that DNSSEC does nothing to stop this either because the whole concept is the origin wants it.

▲cyberax 2 hours ago | parent [-]

> I'm not sure precisely what you mean by "MITM on the server side".

For the vast majority of Let's Encrypt certs, you only need to transiently MITM the plain HTTP traffic between the server and the rest of the net to obtain the certificate for its domain. There will be nothing wrong in the CT logs, just another routine certificate issuance.

It is possible to limit this with, yes, DNS. But then we're back to square one with DNS-based security. Without DNSSEC the attacker can just MITM the DNS traffic along with HTTP.

Google, other browser makers, and large services like Facebook don't really care about this scenario. They police their networks proactively, and it's hard to hijack them invisibly. They also have enough ops to properly push the CAA records that will likely be visible to at least one point-of-view for Let's Encrypt.

▲gzread an hour ago | parent [-]

To detect the misissuance you would run something that compares the certs requested by the server with the certs actually issued and included in the log. If you don't care (and most people don't) then you don't detect it.

▲tptacek 6 hours ago | parent | prev [-]

Seriously? I'll give you two differences right off the bat:

1. DNSSEC only protects the name lookup for a host, and TLS/HTTPS protects the entire session.

2. People actually rely on TLS/HTTPS, and nobody relies on DNSSEC, to the point where the root keys for DNSSEC could be posted on Pastebin tonight and almost nobody would have to be paged. If the private key for a CA in any mainstream browser root program got published that way, it would be all hands on deck across the whole industry.

▲indolering 5 hours ago | parent | next [-]

> DNSSEC only protects the name lookup for a host, and TLS/HTTPS protects the entire session.

It only provides privacy, it doesn't verify that the resolver didn't tamper with the record.

>to the point where the root keys for DNSSEC could be posted on Pastebin tonight and almost nobody would have to be paged.

This would very much be a major issue and lots of people would immediately scramble to address it. The root servers are very highly audited and there is an absurd amount of protocol and oversight of the process.

▲tptacek 5 hours ago | parent [-]

Who? Outside of DNS providers, which organizations would need an emergency response to the collapse of DNSSEC security? Be specific; name one. If TLS security collapsed, I could pick a company from the Fortune 1000 at random, and they'd have an emergency response going.

▲indolering 4 hours ago | parent [-]

If DNS PKI is compromised, so is HTTPS. So yes, they would be scrambling too.

▲tptacek 4 hours ago | parent [-]

This is obviously not true.

▲indolering 3 hours ago | parent [-]

DNS is where domain name authority is delegated. Anything you build on top of that is also going to be a world of hurt if it gets compromised.

▲akerl_ 3 hours ago | parent | next [-]

So why are we not constantly seeing real world compromises of major sites that don't use DNSSEC?

▲gzread an hour ago | parent [-]

Here's one: https://notes.valdikss.org.ru/jabber.ru-mitm/

▲akerl_ 29 minutes ago | parent [-]

I don't see any indication that DNSSEC would have been relevant there? Their assessment was that that interception (and certificate issuance) were completed by redirecting traffic for the legitimate IPs to another destination. The DNS records continued to work as expected.

▲tptacek 3 hours ago | parent | prev [-]

You're doing a jazz-hands thing here where you equate a breach in DNSSEC (which virtually nobody uses), to a new susceptibility in the ordinary DNS (which everybody uses), such that an attacker could spoof arbitrary DNS lookups to arbitrary CAs. Obviously the two things aren't comparable.

When you make arguments like this, or the weird SSH argument you're making across the thread, or the weird "this would be good for Wikileaks" thing you did elsewhere, you clarify how tenuous your argument is. Remember, you're in the position of arguing that 95%+ of large site operators are wrong about this, and have been for decades, and you're the one who's right. That can definitely happen! But it's an extraordinary claim and your evidence thus far is pretty terrible.

▲cyberax 4 hours ago | parent | prev [-]

DNSSEC can be trivially used with DANE to protect the entire session. The browser vendors quite consciously decided to NOT do that.

> 2. People actually rely on TLS/HTTPS, and nobody relies on DNSSEC

Sure. But I treat it as a failing of the overall ecosystem rather than just the technical failure of DNSSEC. It's not the _best_ technology, but it's also no worse than many others.

This is the outcome of browser vendors not caring at all about privacy and security. Step back and look at the current TLS infrastructure from the viewpoint of somebody in the 90-s:

You're saying that to provide service for anything over the Web, you have to publish all your DNS names in a globally distributed immutable log that will be preserved for all eternity? And that you can't even have a purely static website anymore because you need to update the TLS cert every 7 days? This is just some crazy talk!

(yes, you technically can get a wildcard cert, but it requires ...drumroll... messing with the DNS)

The amount of just plain brokenness and centralization in TLS is mind-boggling, but we somehow just deal with it without even noticing it anymore. Because browser vendors were able to apply sufficient thrust to that pig.

▲ekr____ 3 hours ago | parent [-]

> DNSSEC can be trivially used with DANE to protect the entire session. The browser vendors quite consciously decided to NOT do that.

100%. The reasons why are explained in some detail here: https://educatedguesswork.org/posts/dns-security-dane/. The TL;DR is that by the time DANE was created the WebPKI already existed and was universal and so adding DANE didn't buy you anything because you still were going to have to have a WebPKI certificate more or less in perpetuity.

> This is the outcome of browser vendors not caring at all about privacy and security.

This is false. The browser vendors care a great deal about privacy and security. Source: it was my job at Mozilla to care about this, amongst other things. It may be the case that they have different priorities than you.

> You're saying that to provide service for anything over the Web, you have to publish all your DNS names in a globally distributed immutable log that will be preserved for all eternity?

Well, back when people were taking DNSSEC and DANE more seriously, there was a lot of talk of doing DNSSEC Transparency.

> And that you can't even have a purely static website anymore because you need to update the TLS cert every 7 days? This is just some crazy talk!

This is hyperbole, because nobody is forcing you to update the TLS cert every 7 days. It's true that the lifetimes are going to go down to 45 days eventually and LE offers 6 day certificates, but those are both optional and non-default.

Moreover, the same basic situation applies to DNSSEC, because your zone also needs to be signed frequently, for the same underlying reason: disabling compromised or mississued credentials.

▲cyberax 2 hours ago | parent [-]

> The TL;DR is that by the time DANE was created the WebPKI already existed and was universal and so adding DANE didn't buy you anything because you still were going to have to have a WebPKI certificate more or less in perpetuity.

Yet somehow they managed to wrangle hundreds of CAs to use the CT logs and to change the mandated set of algorithms.

> Well, back when people were taking DNSSEC and DANE more seriously, there was a lot of talk of doing DNSSEC Transparency.

And this would have been great. But it only needs to make transparent the changes in delegation (actually, only DS records) from the TLD to my zone. Not anything _within_ my zone.

And tellingly, the efforts to enable delegation in WebPKI are going nowhere. Even though X.509 is supporting it from the beginning (via name constraints, a critical extension).

> This is hyperbole, because nobody is forcing you to update the TLS cert every 7 days.

The eventual plan is to have shorter certs. 47 days will be mandated by 2029.

It also doesn't really change my point: I can't have a purely static server anymore and expect it to be accessible.

> Moreover, the same basic situation applies to DNSSEC, because your zone also needs to be signed frequently, for the same underlying reason: disabling compromised or mississued credentials.

That's incorrect. I've been using the same key (inside my HSM) since 2016. And I don't have to update the zone if it's unchanged. DNSSEC is actually _more_ secure than TLS, because zone signing can be done fully offline. With TLS, the key material is often a buggy memcpy() away from the corrosive anonymous Internet environment.

So you can rotate the DNSSEC keys, but it's neither mandated nor necessary. The need for short-lived certs for TLS is because there's no way to check their validity online during the request (OCSP is dead and CRLs are too bulky). But with DNSSEC if at any point my signing key is compromised, I can just change the DS records in the registrar to point to my updated key.

▲ekr____ 2 hours ago | parent [-]

> > The TL;DR is that by the time DANE was created the WebPKI already existed and was universal and so adding DANE didn't buy you anything because you still were going to have to have a WebPKI certificate more or less in perpetuity. > > Yet somehow they managed to wrangle hundreds of CAs to use the CT logs and to change the mandated set of algorithms.

I'm not sure I see the connection here. What I'm saying is that the benefit for sites to adopt DANE is very low because as long as there are a lot of non-DANE-using clients out there they still need to have a WebPKI cert. This has nothing to do with CT and not much to do with the SHA-1 transition.

Re: your broader point about static sites, I don't think you're correct about the security requirements. Suppose for the sake of argument that your signing key is compromised: sure you can change the DS records but the attacker already has a valid DNSSEC record and that's sufficient to impersonate you for the lifetime of the record (recall that the Internet Threat Model is that the attacker controls the network so they can just send whatever DNS responses they want). What prevents this is that the records expire, so the duration of compromise is the duration of those records, just like with the WebPKI without revocation [0]. The same thing is true for the TLSA records signed by your ZSK.

In the DNSSEC/DANE paradigm, then, there are two signatures that have to happen regularly:

- The signature of the parent over the DS records, attesting to your ZSK. - The signature of your ZSK over the TLSA records.

In the WebPKI paradigm, the server has to regularly contact the CA to get a new certificate. [1]

I agree with you that one advantage of DNSSEC is that that signing can all be done offline and then the data pushed up to the DNS servers, but it's still the case that something has to happen regularly. You've just pushed that off the TLS server and into the DNS infrastructure.

More generally, I'm not sure what you mean by a "purely static server". TLS servers are inherently non-static because they need to do the TLS handshake and I think the available evidence is the ACME exchange isn't that big a deal.

[0] As an aside, all the major browsers now have some compressed online revocation system, but that's not necessarily a generalizable solution.

[1] When we first were designing LE and ACME, I advocated for the CA to proactively issue new certificates over the old key, but things didn't end up that way, and of course you'd still need to download it.