The roundup of implementation hurdles is gratifying to see (I missed the LWN article about it), since I think it's an under-appreciated cost of getting DNSSEC deployed.
As always, the biggest obstacle to DNSSEC is that it solves a problem nobody really cares about.
Um, he more or less did. Because he could have changes the A or CNAME records and gotten a DV certificate. And that certificate would have been legit, because bit.ly is genuinely subject to Libyan jurisdiction.
Sure, CT would have detected it. And any sane use of DANE (which might require an extension) would require CT plus DNSSEC. And, heck, DNSSEC would benefit greatly from a CT-like validation of domain signing keys.
None of this means that a failure to deploy DNSSEC is a good thing.
The difference is, when a CA mis-issues, browsers can kill the CA, as they have done repeatedly in the last few years, to some of the biggest names in the business. You cannot do that do a TLD.
Edit: Libya could create a bitly-like service and serve it up at bit.ly right now. What exactly would stop them?
DNSSEC was designed to protect from using forged or manipulated DNS data. Including all other records, like TXT, MX, CERT records, SSH fingerprints, IPSec public keys and TLS Trust Anchors.
I care that I can verify all this.
The TLS WG has a piece of work for how you shove the DNSSEC RRs into a TLS setup, so you can say "OK, I know DNSSEC but my resolver sucks, so, can you prove who you are with DNSSEC?" as an alternative to doing the Web PKI or some similar setup but with a private CA.
For example we saw this previously with OCSP in two ways: Firstly, any issuer working at scale does OCSP by pre-generating answers and shoving them into an ordinary CDN / reverse cache. The CA knows they issued cert X, and it was still good on Friday, they sign an OCSP response that says "I'm the issuer, cert X was still good as of today" dated Friday and they shove that into the cache. Now the CDN can deliver OCSP responses quickly and at scale without scattering OCSP signer keys all over the Internet. Clients can trust them because they're signed, even though the client talked to some CDN, not the issuer at all.
Secondly OCSP stapling. Instead of clients doing OCSP (and most often failing open since it's unreliable) let's have the server collect OCSP responses for its certificates periodically, and then "staple" the response to the certificate when delivering it. The OCSP signer and OCSP client never communicate at all, but since it's a signed message the client can trust that it's genuine.
Even old GnuPG deprecates DNS based key lookup: https://lists.gnupg.org/pipermail/gnupg-users/2018-October/0...
That said, the only reason for MTA-STS seems to be that some people don't like DNSSEC. From RFC 8461 "Related Technologies The DNS-Based Authentication of a Named Entities (DANE) TLSA record [RFC7672] is similar, in that DANE is also designed to upgrade unauthenticated encryption or plaintext transmission into authenticated, downgrade-resistant encrypted transmission. DANE requires DNSSEC [RFC4033] for authentication; the mechanism described here instead relies on certification authorities (CAs) and does not require DNSSEC, at a cost of risking malicious downgrades."
For me the important thing is that all TLDs I care about support DNSSEC. So I can implement DNSSEC-based security locally. If other people want to play a different game, it is mostly fine with me.
The only annoying part is that browsers refuse to do DANE validation but firefox somehow is very quick to jump on the DoH bandwagon.
It doesn't really matter that you can configure your own little island of DNSSEC since you'll inevitably depend on one of the resources in, like, the whole rest of the Internet, virtually none of which signs zones with DNSSEC. This really all is just security theater.
In the unlikely event that anyone is reading the thread this deeply, you can go to https://dnssec-name-and-shame.com and try to find a big tech firm other than Cloudflare (which has a DNSSEC product) and (heh) Comcast that uses it.
If you live in a centralised internet then what those big parties do is important.
I don't care what version of SSH any of those big parties are running.
Many services have a decentralised version. And when you really care about security, it is worth setting up local servers instead of hoping that those big parties really give you the service you need.
It being optional means that everybody who doesn't like DNSSEC can just ignore it. Just don't sign your zones, don't run a validating resolver. DNSSEC doesn't get in the way.
At the same time, because Google's public resolvers have been validating DNSSEC for quite a long time, it is safe to run a validating resolver. Anybody who signs a zone is forced to do it correctly, otherwise the zone will be unreachable for a significant fraction of the people on the the internet.
Quad9 also provides DNSSEC validation on our primary resolvers. Better for you privacy :)
ARP, and more generally any single-segment Ethernet network, is insecure, and it’s a problem. It’s just a very ingrained problem that’s unlikely to get fixed any time soon.
> The modern Internet was designed with the assumption that the DNS is insecure.
SPF and such may well be designed under the assumption that DNS is
insecure but, under that assumption, they too are insecure.
I kind of wish there was a version of 'Against DNSSEC' that was just about that. The 'Unnecessary' and 'Architecturally Unsound' parts of that argument are so strong, the other bits end up feeling like springboards for DNSSECtarians to launch into debate.
I'm not looking for perfect security or perfect anonymity. Is there nothing better that's available today than the status quo of plain old DNS?
P.S.: I read the related FAQ on sockpuppet.org.
Even with full deployment of eSNI, DNSSEC and DPRIVE it remains practical for an ISP on behalf of your government to track and block IP-level stuff.
It's more expensive than the DNS-level attacks such ISPs mostly use today, but it's entirely practical, governments might choose not to do it (or ISPs might insist on being paid, which forces a government to write a budget line item) because it costs so much, but that'd be the only reason.
This buys the attacker very little. If they can see the packets on your network to read your DNS traffic, then they already know what servers you are communicating with.
So with this combo you would be unable to determine which HTTPS sites I am visiting that are hosted on Cloudflare.
This style response is what I keep seeing whenever a new security enhancement to DNS and TLS is announced. Yes, today 2 things are broken... but that means two things need to be fixed not that this new fix is foolish/useless/shouldn't be implemented.
Now if you have particular takes against the way the problem was solved that'd be a more serious conversation.
DNSSEC brings quite a bit of complexity and potential to break things while in a way further centralizing control (with CAs, at least there's multiple to choose from), so without the second half it seemed like a small gain at high cost.
In the mean time Happy Hardware Hacking because you know your existing security methods cant detect it, but your CPU fan may be the only indicator you have that some malware is running alongside your OS, in a QubesOS/Hypervisor style manner with a coreboot/libreboot bios gone rogue.
Prove me wrong!
> (...) but who knows what secure websites are signed by Digicert or some other CA?
Well, what would be that "secure DNS" in your opinion?
If you assume someone can subvert Digicert would they be able to subvert that "secure DNS" too?
The big differences are 1) you can choose a domain under a gTLD that isn't run by an American company (or other country that is part of your threat model), 2) you can choose to run your own gTLD (at a certain cost), 3) admittedly Certificate Transparency for CAs is much further along than CT for DNSSEC, you're right.
Also, I don't understand how you can pick Google as an example with a straight face. The most commercially important websites in the western world are all run by companies that are controlled by Five Eyes governments.
I'm not even opposed to that! (I'm not a fan of NameCoin, or any-coin at all, but whatever). I just think, be coherent about things.
Depending on your use case, a better approach might be to host your server in the Tor network, in which case NameCoin would indeed make some sense: