First-ever DNSSEC root key rollover | Hacker News Reader

First-ever DNSSEC root key rollover

redhat.com

132 pointsdanyork70 comments

This was supposed to have happened a year ago (I think almost to the day?), but was aborted roughly a week before because nobody was confident the system would survive. Apparently it did this time!

An unfortunate attribute of DNSSEC: nothing depends on it, to the extent that you could almost certainly post the root private keys on Pastebin and not cause a single mainstream site a problem. At the same time, if you screw the deployment of DNSSEC up, sites vanish off the Internet, like HBO Now did, on Comcast, the week of its debut.

Here's a fun exercise. In the thread below, someone brought up https://dnssec-name-and-shame.com (warning: makes annoying noises). Try to find the largest commercial site on the Internet you can that has adopted DNSSEC. Try, for instance, tech giants, or national banks and financial institutions. (Do you want me to spoil this for you?)

Ultimately, this key rollover is sort of interesting in a network nerdery kind of way, but it is no practical importance to anyone, because, after almost 3 decades of attempts, DNSSEC is over; stick a fork in it.

You make some interesting points, but it's worth adding a little extra context. For example, you mention a period of "almost 3 decades" for DNSSEC, but the first RFC for it was published barely two decades ago in 1997: https://tools.ietf.org/html/rfc2065

As a comparison, the RFC for IPv6 was first published two years earlier, in 1995: https://tools.ietf.org/html/rfc1883 and you could say that "nothing depends on" this too, in that no big commercial sites are served IPv6 only.

The fact that no sites would be taken down if the root private keys were published isn't too surprising either. What would happen if the Let's Encrypt (IdenTrust) private keys were published? Perhaps browsers would do the principled thing and brick ~50% of secure websites: https://w3techs.com/technologies/history_overview/ssl_certif... but I suspect that some pragmatic solution would be found. (In such a situation, though, it would be nice if sites could use TLSA as a defence in depth).

I think that the biggest differences, in terms of adoption rate, are that there isn't a limited supply of non-DNSSEC domain names (unlike the pressure to upgrade from IPv4 to IPv6), and sites don't get a Google search ranking boost (or a shiny padlock in the browser UI) by implementing DNSSEC. Remember that until quite recently even HTTPS was the exception rather than the norm for popular websites.

DNSSEC precedes its first RFC by several years; before that RFC, it was a DoD-funded project run by Trusted Information Systems. It's different today in a variety of ways, but the fundamental design decisions --- offline signers, authenticated denial --- date back to TIS and the USG.

If LetsEncrypt broke, there would be absolute chaos across the Internet.

Maybe, but LetsEncrypt breaking would be fixed much faster than any other CA as it’s the only one where every user is automated.

Contrast that with the legacy model and the emailed zip files of cert chains alone would flood the intertubes.

I like LetsEncrypt and wasn't trying to suggest it was a problem. I think the comparison between LetsEncrypt and DNSSEC is instructive; a LetsEncrypt confidentiality failure would be disastrous, and a DNSSEC confidentiality failure... actually wouldn't matter at all, unless someone out there is doing something really creative and dumb with the protocol.

This might actually be a bad point for letsencrypt. All the eggs are starting to be in the same basket.

If your failures don't count, you're not doing anything important.

Big five tech giants aren't playing, and I don't know any bank domains, but it's not hard to find names:

cloudflare.com verisign.com comcast.net *.gov

Every time dnssec shows up there's a tptacek comment crapping on the medium. are you using google alerts or something? what were your consulting fees for this service?

Cloudflare and Verisign are no surprise; Cloudflare has a DNSSEC product, and Verisign is effectively one of the sponsors of the protocol. For what it's worth: Akamai does DNSSEC, too.

Comcast is indeed DNSSEC-signed (how you know Comcast does DNSSEC is, as I said, they sort of infamously broke an HBO product launch with it). But, for instance: Verizon and AT&T are not!

Also first national bank I tried to look up, (actually don't know if that's what you mean by national bank)

federalreserve.gov is using dnssec.

Sorry, I meant nationwide banking chains, like Bank of America. .GOV has, from years back, a mandate to adopt DNSSEC.

Every time dnssec shows up there's a tptacek comment crapping on the medium.

I know, right? Glad I’m not the only one to notice…

For example Thomas likes Let's Encrypt but he's stuck with his narrative about how nothing uses DNSSEC. So when you point out that Let's Encrypt uses DNSSEC so this position makes no sense, Thomas will just pretend not to understand and refer you back to stuff he wrote many years ago about how nothing uses DNSSEC.

LetsEncrypt does not rely on DNSSEC and does multi-perspective DNS lookups. Something significantly south of 0.5% of LetsEncrypt certificates ever involve DNSSEC.

If DNSSEC vanished tomorrow, literally nothing about LetsEncrypt would change. There would be no operational impact whatsoever.

Not that there's anything wrong with the pieces I wrote "years ago" about DNSSEC (nothing material has changed about it since I wrote that), but I didn't do that here: I provided new evidence that nobody is using DNSSEC, and it is up-to-the-minute. Practically no mainstream sites use DNSSEC, as everyone can see for themselves at the link at the root of this thread.

Those "multi-perspective" validations have been stalled for over a year. The last news is from August 2017. Unlike many issuers Let's Encrypt notoriously does fresh validations for most issuances and they start with a DNSSEC validated authoritative DNS query chain. So, that's 100% of validations, and perhaps 95% of all issuances. Not 0.5% as you've claimed.

When you wrote your jolly screed against DNSSEC the biggest CAs relied heavily on "Any other method" blanket exemptions which no longer exist today. They also used to insist that their extremely high issuance rates made DNSSEC and other security features just infeasible.

After CT this last part got awkward. Where, a neutral party like me might ask, are the doubtless hundreds of millions of certificates you've been issuing that would make this so hard? And of course they don't exist, it was a bluff and now their bluff has been called.

An infinitesimal fraction of the domains LetsEncrypt issues certificates for are signed. I kind of don't understand how you're even trying to make this argument. Everyone here who has ever set up LetsEncrypt knows there's no DNSSEC involved. LetsEncrypt does not depend on DNSSEC; if DNSSEC vanished tomorrow, there would be no operational impact.

Here, try this: search for "LetsEncrypt tutorial", go through the first two search pages, and find one that says "to start with, sign your domain with DNSSEC". Not one in my search results mentions DNSSEC. That's because: nobody cares.

DNSSEC not protecting those who choose not to be protected is entirely to be expected.

Should I assume you figured "nobody cares" about the Web PKI back just a few years when tutorials wouldn't have mentioned TLS? Were people who said that right? Or wrong?

I'm sorry, I can't understand what you're trying to argue at this point. My argument is simply that LetsEncrypt doesn't depend on DNSSEC, and, indeed, it does not.

Me describing how these conversations go: > Thomas will just pretend not to understand

Thomas just now: > I'm sorry, I can't understand what you're trying to argue

Let's Encrypt does today depend on DNSSEC because it uses a DNSSEC verifying validator. If you have chosen not to sign names of course your names aren't protected by this, names which are signed are protected.

In a similar way, Firefox does today depend on the Web PKI because it uses NSS, a TLS implementation with a certificate validator baked into it. If you have chosen not to use HTTPS of course your sites aren't protected by this, sites which use HTTPS are protected.

You're simply using a different definition of "depend" than I am.

When you say "it does depend", you mean that in the rare cases where a domain owner has chosen (weirdly) to sign with DNSSEC, LetsEncrypt will enforce DNSSEC validation on that domain.

When I say "it does not depend", I mean that the basic functioning of LetsEncrypt does not in any way rely on DNSSEC. As I've said in the last several comments, LetsEncrypt will continue to function just fine when DNSSEC goes away, and a security failure in DNSSEC (for instance: if the root keys were posted to Pastebin) would literally not impact LetsEncrypt --- today's LetsEncrypt! --- at all.

I'm fine with you using the word "depend" to mean "uses, in any situation, ever", but you're clear now on what we're trying to say, and the semantic part of the debate should be over.

what were your consulting fees for this service?

Keep this ad hominem nonsense off HN, please.

Excuse me, this is a thread from the front page of the site, on a topic I happen to have a position on. Please don't be rude.

This comment breaks the site guidelines and your one downthread is even worse. You can't attack another user like that on HN, and we ban accounts that do it. Please review https://news.ycombinator.com/newsguidelines.html and follow the rules when posting here, regardless of how wrong you think someone is about something.

But mitre.org uses it!

Actually nearly all the sites I could find that used it were in some way government related. I even tried a half-dozen universities, since they often adopt obscure internet standards, and uiowa.edu was the only one I found that implemented it.

I seriously don't understand why you are so much against DNSSEC. Just about every HN article that involves DNS had one of your anti-DNSSEC rants in them.

Yes, we know DNSSEC has some flaws, but how is DNSSEC worse than the alternative, which is no zone signing at al?

> if you screw the deployment of DNSSEC up, sites vanish off the Internet.

If you screw up your TLS certificate, your site also vanishes off the internet, should we also give up on HTTPS then?

DNSSEC is much worse than the alternative, which is no zone signing at all. If you screw up your TLS certificate, your site does not vanish off the Internet.

DNSSEC is something I've studied and worked on (I'm one of [I assume] the few people on this site that has built a working implementation of it) for going on two decades right now. Sorry, I have opinions and a position on it, they're informed opinions, and you're going to have to suffer them.

> This was supposed to have happened a year ago

The article says that this HAPPENED a year ago:

> Note that this has been included for at least a year now [...]

It's the "first ever" DNSSEC root key rollover, so, no, it didn't happen a year ago.

What is the purpose of rolling over the key, if the new key is simply signed by the old one? Meaning it has exactly as much security as the old key did.

I can understand it if the new key was a different algorithm, or key-length or something. But what is the purpose in simply picking a new key?

The old one will presumably eventually be expired. That means someone who compromised the old one can't hang onto their access indefinitely.

Yes. To add to this, in order for an attacker in this situation to maintain their access, they would have to perform a very visible active attack. If not for this they would be able to maintain their access passively.

If someone compromised the old one, it would be already catastrophic. Key rotations are mostly about compliance requirements and are also mostly rubbish.

If the old key has been unknowingly compromised, it is now replaced. The new key is not "simply" signed by the old one. You have to announce it for 30 days, making it harder to pull of a surreptitious switch.

The new key is simply newer. For especially valuable keys we must assume that an adversary is trying to break them, even if this will be difficult and expensive. But by changing keys, we undo all the work invested so far into breaking a key, since the key they were breaking won't even be used any more.

This was the rationale behind password change frequency rules too. If I can try 100 passwords per day, and I'm sure you've picked 1 of 1000000 passwords I have a good chance to find which one in a few years. But if you're forced to change it every 6 months then I'll never have more than a small chance to get it.

Suppose it takes a government agency 25 years to break a key, and you replace keys every 10 years. So they start on key A in year zero, in year 10 you switch to key B, in year 20 to key C, and then in year 25 they've broken A - but who cares everybody is using C now.

You might think well they could start working on C from the outset. No. The keys are not chosen long in advance, you can't break C until it has been chosen.

> This was the rationale behind password change frequency rules too. If I can try 100 passwords per day, and I'm sure you've picked 1 of 1000000 passwords I have a good chance to find which one in a few years. But if you're forced to change it every 6 months then I'll never have more than a small chance to get it.

This is not how probability works. Password rotation is intended to prevent long term compromises from existing due to a leaked password. I'd debate if this actually has any effect, but that's another matter entirely.

> if this actually has any effect

It has the effect of limiting the amount of time that a credential leak can lead to exploit. The focus is on long-term undiscovered compromise using valid credentials. If an attack is not discovered, and the credentials are never changed, the attacker might have access for years. If you're worried about something like corporate espionage, this mitigation is simple and minimal effort.

For really sensitive credentials, I would shrink the rotation period even more. The more often you're forced to do it, the more likely the process will become smoother.

I argue that most compromises are effectively instantaneous. There’s usually little value in being a persistent threat when it takes only a moment to, for example, dump a database or an IMAP folder. Forcing rapid rotations just encourages people to choose weak passwords or store them on post it notes on their screen.

And groups that value persistence (like APTs) rarely depend on passwords to provide it. Instead they map the environment and find a local vulnerability to exploit and create a place to hang out.

One of my employers had the Chinese in their networks for years. We all dutifully changed our passwords every 90 days and it made no difference at all to the Chinese persistence.

Right. The classic is an email account is compromised, a forward to rule is added, and nobody ever notices. It’s a false sense of security if preventing persistence is the goal. Usually instantaneous access is going to be the most disastrous effect anyway.

>This is not how probability works. Password rotation is intended to prevent long term compromises from existing due to a leaked password. I'd debate if this actually has any effect, but that's another matter entirely.

Yes it is. Let's up the number to 1000 passwords per day. That means that I can check all passwords in the space in 1000 days, or 3 years. In other words, after 1000 days, there is a 100% chance I can access your account.

If on the other hand, you change your password to a new, random password each day, I have a 1/1000 chance of guessing it each day. Then after 1000 days, I have a 1 - (1 - 1/1000)^1000 chance[1] of knowing your password. That is, each day, I guess your password with P = .1%, so there's a 99.9% chance I don't. Then after 2 days, there's a 99.9% chance for day one, and of the remaining 99.9, there's a 99.9% chance I don't, continue on for 1000 days, and there's a 63.2% chance you ever accessed my account, not 100%.

In short, it converts the password cracking attempts form being correlated to uncorrelated over a long time scale.

[1]: As an aside, note that in this example that is ~1 - 1/e.

Some villain might have got a copy of the old key. They won't necessarily have a copy of the new key.

The old key was hosted inside a proprietary appliance and can't be extracted.

https://labs.ripe.net/Members/anandb/the-future-of-dnssec-at...

https://labs.ripe.net/Members/anandb/dnssec-signer-migration """Our old Secure64 signers do not export their private keys. This means that in order to migrate to the new signers, we will have to perform a KSK roll-over."""

I'm pretty sure that's unrelated to the DNSSEC root key which is managed by IANA and not RIPE NCC. https://www.iana.org/dnssec

I'm guessing that's referring to signing the reverse DNS zones for their IP address allocations (193.in-addr.arpa for example) and it's just coincidentally timed with the DNSSEC root key rollover.

Isn’t that a good thing? You don’t want to be able to export keys from a HSM.

Mostly security theater, but it’s still useful to practice a key rollover in case something bad happens.

I have a DNSSEC signed zone, do I need to do anything? Like generate a new key using this new root key?

No, this only impacts configuration on the validation side, not signing.

No, because nobody really depends on DNSSEC, so nothing will break:

- https://ianix.com/pub/dnssec-outages.html

- https://twitter.com/tqbf/status/772103926258671618

> because nobody really depends on DNSSEC

That's not true. A lot of people use DNSSEC validating public resolvers like 1.1.1.1 and 8.8.8.8, especially on Android devices. I use DNSSEC on my personal domain, and when my zone-resigning cronjob fails, I notice pretty quickly, because the page really does fail to load in my browser.

Is that a good thing? That sounds like a pretty solid reason not to deploy DNSSEC.

It's not a good thing. To a first approximation 0% of the mainstream public Internet relies on DNSSEC, so using a DNSSEC-validating resolver will on net get you only new outages; not any additional security, even at the margin.

It's a failed protocol that a subset of Linux nerds cheerlead because any classic Internet protocol + "SEC" must be cool, that companies like Cloudflare cheerlead because it's complicated and drives lock-in for them, and that governments cheerlead because it in theory grants control over all web crypto to them.

You can't have DNSSEC outages if no-one is validating DNSSEC. So either there are outages, but a little extra security, or no extra security, but no outages, either.

Sure you can. Virtually no part of the web PKI takes advantage (or ever will take advantage) of DNSSEC. Having DNSSEC enabled on your domain will accomplish nothing for you. But: if you misconfigure DNSSEC, or fail to maintain it, your site will vanish from the Internet for the users that make the mistake of using DNSSEC-validating resolvers. You've gained no security, but you have gained additional outages.

Of course you gain security, but not in the HTTPS PKI sense. Not that long ago, somebody BGP hijacked Route 53 in order to serve up different IP's for specific domains. Had that domain been using DNSSEC, that attack would have failed for everyone using a validating resolver. That might not be a common attack, but it certainly grants security.

This could also help with "rogue" free wifi setups, that try to do something like that as well.

Were the domains using TLS?

Does it matter? If the attackers can redirect the domain names to their own IP addresses then they can obtain DV certificates for those domains. The security of TLS depends on secure domain name resolution.

1. Virtually nobody signs zones today, so this is a moot point.

2. Not all DV-issuing CAs reliably verify DNSSEC, so it's even mooter.

3. Even if everyone signed their zones today, the Five Eyes intelligence agencies (NSA, ASD, GCHQ, GCSB, and CSE) have de facto (and, in some cases, de jure) control over the most important TLD zones.

4. The Web PKI already has countermeasures in place to detect misissuances, and those countermeasures have already resulted in the deaths of several of the largest CAs; there is ample evidence that current Web PKI surveillance is up to the task.

5. Even with secure DNS resolution, DV cert verification processes don't have a secure channel, and remain vulnerable to traffic interception attacks; for instance, even with DNSSEC, BGP attacks can straightforwardly trick CAs.

6. There are countermeasures to DNS spoofing that are simpler to deploy than DNSSEC, especially in the limited settings needed for DV cert verification; for instance: multi-perspective DNS and DNS over HTTPS.

7. There is already work happening to link CAs directly to registrars using RDAP to bypass DNS entirely for domain validation. In addition to being more reliable than DNSSEC, RDAP is also drastically simpler to deploy, and doesn't require anyone to sign their zones.

DV certificate issuance and SMTP-TLS were the last two mainstream drivers for DNSSEC adoption. The Web PKI has worked around the problem, and, with SMTP-STS (a standard whose specific, stated rationale is to work around DNSSEC), so have the largest email providers.

In fact: nothing depends on secure domain resolution, all meaningful Internet protocol security work over the last two decades has been premised on DNS being insecure, and DNSSEC is done. Stick a fork in it.

> Even with secure DNS resolution, DV cert verification processes don't have a secure channel, and remain vulnerable to traffic interception attacks; for instance, even with DNSSEC, BGP attacks can straightforwardly trick CAs.

3.2.2.4.7 just does DNS, so DNSSEC can secure it regardless of "traffic interception" or other shenanigans.

Tightening up the Web PKI happens gradually. In 2017 we required the Ten Blessed Methods (3.2.2.4.x) to replace a previous free-for-all, and then we've whittled away those ten so that today there are only eight left, of which one is secured by DNSSEC and several are out-of-band, so shenanigans on the Internet won't help you there. I won't be surprised if it's six by late next year.

Security includes availability and integrity, not just confidentiality.

DNSSEC is a literal textbook case of the trade-off between C and A.

Clients need to update their root keystore, but zones need no change.

But when will it be supported in Route53?

ahmen

But why do you want it? DNSSEC and TLS cover much of the same use cases - except DNSSEC is worse. IIRC, it uses 1024bit RSA keys - which are large, and yet not particularly strong. It gives you very little flexibility - if you own example.com, you have to trust the root key and Verisign and whatever governments have authority over them and the only way out is to change to a different domain name. And what seemed like the most interesting technology enabled by DNSSEC (DANE) has no browser uptake (for good reason).

Until rather recently, the root DNSSEC keys were RSA-1024, but the roots are now RSA-2048 (which is fine). But the rest of the DNSSEC PKI is positively littered with RSA-1024 keys (for instance: there's one in .COM).

If your attack model includes Verisign or a government modifying your DNS zone, then that will allow them to obtain a DV certificate as well.

By and large, TLS security depends on the connectness of DNS. Though you could try your luck with HTTP public key pinning (HPKP).

I fully agree that 1024 bit keys are silly.

HPKP is about to only be usable on Firefox since IE/Edge never supported it and Chrome has deprecated and is about to remove it.

I want it because above my pay grade has decided, for "reasons" they want it. These reasons, that I may or may not agree with, are valid and reasonable. It's my role to implement. We have loads of other services in AWS but because of our DNSSEC requirement we can't use that one. It's a minor technical headache the Ops team has to deal with -- 99% in AWS except this other critical piece.

To check DNSSEC:

https://dnssec-name-and-shame.com

To check DANE (such as freebsd.org port 443):

https://www.huque.com/bin/danecheck

The dnssec-name-and-shame site makes an incredibly loud noise if the site you type in happens to not be compliant or whatever. Be sure to remove your headphones before clicking any links in the above comment.

Reply on news.ycombinator.com