Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

First-ever DNSSEC root key rollover

redhat.com

Post reply on HN
Print view View original

11–20 of 75 posts

Re: First-ever DNSSEC root key rollover

#11

Post by tialaramex »

ars wrote: post #8

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

Re: First-ever DNSSEC root key rollover

#12

Post by twic »

ars wrote: post #8

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?

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

Re: First-ever DNSSEC root key rollover

#13

Post by mappu »

ars wrote: post #8

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

Re: First-ever DNSSEC root key rollover

#14

Post by benchaney »

lmm wrote: post #9
ars wrote: post #8

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.

Re: First-ever DNSSEC root key rollover

#15

Post by [deleted] »

tialaramex wrote: post #11
ars wrote: post #8

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

[deleted]

Re: First-ever DNSSEC root key rollover

#16

Post by RL_Quine »

tialaramex wrote: post #11
ars wrote: post #8

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

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

Re: First-ever DNSSEC root key rollover

#18

Post by tptacek »

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.

Re: First-ever DNSSEC root key rollover

#19

Post by peterwwillis »

RL_Quine wrote: post #16
tialaramex wrote: post #11

Earlier quoted context omitted.

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…

> 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 e…

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

Re: First-ever DNSSEC root key rollover

#20

Post by RL_Quine »

peterwwillis wrote: post #19
RL_Quine wrote: post #16

Earlier quoted context omitted.

> 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 e…

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

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.
Post reply on HN