9 ms·

First-ever DNSSEC root key rollover

132 points by danyork 8y ago

ancarda 8y ago
I have a DNSSEC signed zone, do I need to do anything? Like generate a new key using this new root key?
- kijeda 8y ago
  No, this only impacts configuration on the validation side, not signing.
- dchest 8y ago
  No, because nobody really depends on DNSSEC, so nothing will break: - https://ianix.com/pub/dnssec-outages.html https://ianix.com/pub/dnssec-outages.html - https://twitter.com/tqbf/status/772103926258671618 https://twitter.com/tqbf/status/772103926258671618
  - rossy 8y ago
    > 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.
    - dagenix 8y ago
      Is that a good thing? That sounds like a pretty solid reason not to deploy DNSSEC.
      - tptacek 8y ago
        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.
        codebje 8y ago
        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.
        tptacek 8y ago
        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.
        colde 8y ago
        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.
        the_clarence 8y ago
        Were the domains using TLS?
        nybble41 8y ago
        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.
        tptacek 8y ago
- rrrguy 8y ago
  Clients need to update their root keystore, but zones need no change.
anon49124 8y ago
To check DNSSEC: https://dnssec-name-and-shame.com https://dnssec-name-and-shame.com To check DANE (such as freebsd.org port 443): https://www.huque.com/bin/danecheck https://www.huque.com/bin/danecheck
- jrockway 8y ago
  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.
ars 8y 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?
- lmm 8y ago
  The old one will presumably eventually be expired. That means someone who compromised the old one can't hang onto their access indefinitely.
  - benchaney 8y ago
    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.
  - the_clarence 8y ago
    If someone compromised the old one, it would be already catastrophic. Key rotations are mostly about compliance requirements and are also mostly rubbish.
- tedunangst 8y ago
  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.
- tialaramex 8y ago
  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.
edoceo 8y ago
But when will it be supported in Route53?
- markwakeford 8y ago
  ahmen
- dagenix 8y ago
  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).
  - tptacek 8y ago
    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).
  - phicoh 8y ago
    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.
    - zamadatix 8y ago
      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.
  - edoceo 8y ago
tptacek 8y ago
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 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.
- dane-pgp 8y ago
  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 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 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_certificate 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.
deleted 8y ago
[deleted]

132 points by danyork 8y ago

ancarda 8y ago

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

kijeda 8y ago
No, this only impacts configuration on the validation side, not signing.
dchest 8y ago
No, because nobody really depends on DNSSEC, so nothing will break: - https://ianix.com/pub/dnssec-outages.html https://ianix.com/pub/dnssec-outages.html - https://twitter.com/tqbf/status/772103926258671618 https://twitter.com/tqbf/status/772103926258671618
- rossy 8y ago
  > 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.
  - dagenix 8y ago
    Is that a good thing? That sounds like a pretty solid reason not to deploy DNSSEC.
    - tptacek 8y ago
      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.
      - codebje 8y ago
        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.
        tptacek 8y ago
        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.
        colde 8y ago
        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.
        the_clarence 8y ago
        Were the domains using TLS?
        nybble41 8y ago
        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.
        tptacek 8y ago
rrrguy 8y ago
Clients need to update their root keystore, but zones need no change.

anon49124 8y ago

To check DNSSEC: https://dnssec-name-and-shame.com https://dnssec-name-and-shame.com To check DANE (such as freebsd.org port 443): https://www.huque.com/bin/danecheck https://www.huque.com/bin/danecheck

jrockway 8y ago
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.

ars 8y 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?

lmm 8y ago
The old one will presumably eventually be expired. That means someone who compromised the old one can't hang onto their access indefinitely.
- benchaney 8y ago
  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.
- the_clarence 8y ago
  If someone compromised the old one, it would be already catastrophic. Key rotations are mostly about compliance requirements and are also mostly rubbish.
tedunangst 8y ago
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.
tialaramex 8y ago
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.

edoceo 8y ago

But when will it be supported in Route53?

markwakeford 8y ago
ahmen
dagenix 8y ago
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).
- tptacek 8y ago
  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).
- phicoh 8y ago
  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.
  - zamadatix 8y ago
    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.
- edoceo 8y ago

tptacek 8y ago

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

dane-pgp 8y ago
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 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 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_certificate 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.

deleted 8y ago

[deleted]