2048-bit RSA is “weak”? If I understand things correctly, 2048-bit keys are considered safe for more than ten years still, and the design of DNSSEC is such that the root keys can be rolled over at any time, so when the time comes, the key can simply be substitued for a stronger one.
And the comparison with X.509 is unsuitable. The DNSSEC root key could be compromised? How about the fact that if any CA loses its key, the entire X.509 system is vulnerable until that key can be revoked by every single end user?
2048 bit keys? What about all the 1024 bit keys that litter the DNSSEC PKI?
How about the fact that CA keys can be revoked? Google and Mozilla killed one of the largest CAs in the market for misissuance. How do you kill .COM? You think if Symantec had a say in the matter, they'd let Google kill their CA business? How about the fact that weeks after the KSK roll, more than half the Internet still depends on the old root key?
> What about all the 1024 bit keys that litter the DNSSEC PKI?
You’re moving the goalposts. The parent comment was explicitly about the root key. Yes, there are still weak keys below the root, just as there are still weak certifikates with MD5 hashes out there, but that is neither here nor there.
Just to clarify, bluejekyll referred to the root keys as a "somewhat weak RSA key", you pointed out that the root keys are 2048 bit, and tptacek responded pointing out that while the root keys are 2048 bit, the chain between them and basically any site with DNSSEC has 1024 bit keys involved.
That's not really "moving the goalpost", so much as "a conversation involving more than 2 people".
I pulled up the chain for cloudflare.com on the grounds that they'd care more than the average site about DNSSEC, and here was the result: http://dnsviz.net/d/cloudflare.com/dnssec/
So that's a 2048 bit root, and then as the chain passes through .com there's a 1024 bit RSA key, and then they have ECC keys for their zone. If their TLS cert had a hop in the chain that used MD5 hashes, Chrome would be refusing to trust their site.
Firstly, now that the root has a 2048 bit key, I predict that the rest of the TLDs will follow soonish. Previously, the concept was unproven, but now that it has been proven to work, I assume that keys will be rolled and progress will be made.
Secondly, as I understand it, a 1024-bit RSA key, while not recommended, is still vastly more secure than an MD5 hash.
On the first point: quite a few DNSSEC records use ECC keys, and have for a while. If your hypothesis holds, why not switch the root 2048 bit RSA keys, and those TLD-level 1024 bit keys, for ECC keys?
On the second: MD5 is one example, but the browser blacklists SHA1 as well. It also blacklists CAs that behaved poorly in the past, and refuses to use vulnerable ciphers.
> why not switch the root 2048 bit RSA keys, and those TLD-level 1024 bit keys, for ECC keys?
Because this is the first time they ever switched the root key, and they want to observe the effects a bit more first? My prediction assumes that it works and sufficient time will pass. Also, ECC keys are not yet as widely supported by resolvers as RSA keys are. This, too, will require experimentations and time for conversion to be viable.
You're conceding a huge problem with DNSSEC. Yes, support for ECC isn't great. Either RIPE or APNIC was tracking it and last I saw something like 1/3 of the deployed base can't handle it, meaning effectively that everyone is stuck with the lowest common denominator of RSA and ECDSA. Meanwhile: the p-curve ECDSA that we're talking about seeing deployed is already very outmoded. And, unlike RSA PKCS1v15 signatures, where the concerns are theoretical and not practical, P-curve ECDSA is practically problematic. It could take a decade to get to the 2018 standard for curve security (presumably, a Schnorr-like construction on a curve like 25519).
Meanwhile: nobody relies on DNSSEC today. I'm not kidding when I say the root keys could land on Pastebin tonight and almost nobody would have to work late or even get paged.
Doesn't it seem just sort of plainly obvious that we should drop a flag on the broken protocol we're looking at now and re-do it properly with modern cryptography?
> Doesn't it seem just sort of plainly obvious that we should drop a flag on the broken protocol we're looking at now and re-do it properly with modern cryptography?
What makes you think that people will support this hypothetical new protocol faster than adding support for good crypto types in DNSSEC?
I mean, is that really what you are suggesting as the proper course of action? Throw away DNSSEC and have nothing replacing it until a new protocol is standardized and implemented as widely?
Because alternative approaches have been deployed far faster than DNSSEC. The obvious example to point to would be DoH.
Yes: we should throw away DNSSEC and have nothing replace it until something better is available. Nobody relies on DNSSEC today! I feel like that point just isn't sinking in with you. Take some time and consider its impact. 25+ years after the work started: nobody relies on DNSSEC at all. DNSSEC simply does not matter right now. That's not hyperbole; it's a statement of fact.
People have been predicting that since before Adam Langley wrote "Why Not Dane In Browsers", and making excuses about the keys that are there. Nobody denies that a 1024 bit RSA key is less bad than an MD5 certificate; it's still quite bad, and, personally, I'd argue, the worst kind of bad --- the kind of flaw that motivates large capital and operational expenditures at intelligence agencies.
Even if every key below the root were 1024 bits, why would this be an argument against the concept of DNSSEC in general? DNSSEC keys can, by design, be rolled and replaced, and people will replace them as soon as they feel it is reasonably safe to do so.
The perfect is the enemy of the good. What is the intended result of advocating for choosing not to adopt DNSSEC? Is this intended result actually likely, or is it more like a boycott for the principle of the thing?
I don't think I can answer this any more effectively than I did in "Against DNSSEC", linked upthread. I'll just point out that the bad is also the enemy of the good.
A “bad” which is by design fixable as time passes, is much better than a theoretical “good” which is not currently commonly supported, and isn’t looking likely to be such any time soon.
No, modern browsers won't honor MD5 (or, for that matter SHA-1) certificates. But there's nothing they can do about 1024 bit RSA keys in DNSSEC. Starting to see the pattern?
Sorry, weak was perhaps the wrong term, it’s more the management that’s at issue. You can see the sibling comments that of course argue that perspective more accurately.
> Sorry, weak was perhaps the wrong term, it’s more the management that’s at issue.
“weak” was about half of your original argument:
> The general argument is that X509 with TLS is enough authentication of a site one is connecting to, and therefor DNSSEC being somewhat weak, is something unnecessary.
If we discount “weak”, let me then reply to the remainder of it:
Firstly, DNSSEC is not only for web traffic, DNSSEC secures DNS for everything which uses ___domain names to locate services, not only HTTP. This is a big deal not only for more obscure (not to mention future) protocols, but also for sending e-mail, the MX lookup phase of which is otherwise unsecured.
Secondly, the general problem with X.509 with rogue CA’s remain, and the only counter I have seen is akin to “but we can close those barn doors really well after each individual horses escape”, and I remain unconvinced.
Thirdly, how do you prove you own a ___domain enough to get a X.509 certificate? You answer DNS requests, which is spoofable unless secured by DNSSEC.
One of the two major remaining use cases for DNSSEC was in protecting mail infrastructure, which has a less-sophisticated PKI (for lack of a better term) than the web. But the major mail providers --- including Google, Yahoo, and Microsoft --- have given up on DNSSEC (note that none of them are DNSSEC-signed) and have together generated SMTP-STS, which does for SMTP what HSTS does for websites: after a first rendezvous connection, all subsequent connections are protected by continuity rules rather than policy.
The SMTP-STS standard is explicit that it is motivated by the desire not to rely on DNSSEC.
The other major use case for DNSSEC is, as you suggest, protecting DV verification. But in the long term, DNS is going to get factored out of ___domain verification entirely. CAs will eventually (who knows how long it will take, even though the protocols are there) just verify domains directly with registrars using something built on RDAP. In the meantime, there are countermeasures against DNS spoofing (that have the virtue of also working against BGP spoofing, which DNSSEC doesn't fix) that the CAs can (and gradually do) deploy.
It's hard to see the justification for rolling out an expensive, inferior protocol to mitigate attacks that we're already adequately mitigating today and will in the future decisively address through other means.
The major providers also “gave up” on SRV records for HTTP/2, but that does not make it a bad idea – on the contrary, SRV for HTTP would be a good idea for the rest of us. But not for Google, since not having it cements their position.
> But in the long term, DNS is going to get factored out of ___domain verification entirely. CAs will eventually (who knows how long it will take, even though the protocols are there) just verify domains directly with registrars using something built on RDAP.
Get back to me when that actually happens, or looks likely to ever happen. Last I heard, the proposed replacement of WHOIS with RDAP has been put on very thick ice, and it is uncertain what will actually happen.
> It's hard to see the justification for rolling out [DNSSEC] (…)
In my world, that ship has long sailed. DNSSEC is fully rolled out. I work for a ___domain name registrar, and more than 30% of all the domains we manage are DNSSEC signed, and we could easily sign another 30% if we wanted to.
DNSSEC has long been rolled out. It’s too late to argue that it shouldn’t be.
People have been claiming DNSSEC is "rolled out" for almost a decade now (amusingly, they said so before the major TLDs were even signed). You're missing the point: nobody uses it. No major tech company even signs their zone. The browsers don't do DNSSEC lookups --- Firefox and Chrome actually removed their support for it.
People affiliated with registrars are constantly pointing out how many zones they sign, as if that was any kind of argument at all. Look, nobody doubts that you can build a feature into your stack that automatically signs zones. 30%? Why not 100%? Who cares? That's just theater. What matters are companies actually relying on the protocol. Nobody does, today.
What comment of mine are you replying to exactly? You seem to have read an awful lot into something where I was trying to help someone understand why there is some conflict here.
I only mentioned X509 as people are going to be more familiar with that than DNSSEC. The reason I mentioned it was to describe it as having a comparable method for validating the chain of certificates/signatures. It is very similar in that regard to X509 certificate chains.
I’ve implemented DNSSEC in my own project, so I know the protocol, and I do agree that for MX records, as well as TXT and other record types that we need to validate that the records are authentic, in many contexts. Not just web and not just public internet, where we might want to pin custom trust anchors.
I can see you are very concerned about this as am I, and if you want to reach out and discuss this in a different forum, I’d be happy to, as I think we have shared interests in seeing this succeed.
2048-bit RSA is “weak”? If I understand things correctly, 2048-bit keys are considered safe for more than ten years still, and the design of DNSSEC is such that the root keys can be rolled over at any time, so when the time comes, the key can simply be substitued for a stronger one.
And the comparison with X.509 is unsuitable. The DNSSEC root key could be compromised? How about the fact that if any CA loses its key, the entire X.509 system is vulnerable until that key can be revoked by every single end user?