Live data from Hacker News

First-ever DNSSEC root key rollover

redhat.com

51–60 of 75 posts

Re: First-ever DNSSEC root key rollover

#51
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?

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

Re: First-ever DNSSEC root key rollover

#52
post #47
post #39

Earlier quoted context omitted.

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

Were the domains using TLS?

Re: First-ever DNSSEC root key rollover

#53
post #32
post #17

But when will it be supported in Route53?

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…

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.

Re: First-ever DNSSEC root key rollover

#54
post #42
post #25

Earlier quoted context omitted.

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?

what were your consulting fees for this service? Keep this ad hominem nonsense off HN, please.

Questioning motives in response to suspicious behavior is not ad-hominem.

Re: First-ever DNSSEC root key rollover

#55

Earlier quoted context omitted.

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.

Re: First-ever DNSSEC root key rollover

#56
post #25
post #18

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

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?

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.

Re: First-ever DNSSEC root key rollover

#57
post #54
post #42

Earlier quoted context omitted.

what were your consulting fees for this service? Keep this ad hominem nonsense off HN, please.

Questioning motives in response to suspicious behavior is not ad-hominem.

I don't know if it's "ad-hominem", but it's specifically called out by the guidelines as something you're not allowed to do here. I'd appreciate an apology.

Re: First-ever DNSSEC root key rollover

#58
post #18

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

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

Re: First-ever DNSSEC root key rollover

#59
post #45
post #18

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

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

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.

Re: First-ever DNSSEC root key rollover

#60
post #37
post #34

Earlier quoted context omitted.

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…

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.

Security includes availability and integrity, not just confidentiality.

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

Post reply on HN