As long as DNS is insecure, Security Services can intercept and reroute IP addresses to send people to the security services version of the internet for brain washing. Installing a fake Certificate Authority on a computer through a zero day remote exploit or domain server hijack from a compromised router lulls users into thinking they are looking at genuine websites, but who knows what secure websites are signed by Digicert or some other CA? Just because its secure doesn't mean its not fake. IEEE standards are woefully inadequate and not joined up, but then one of the largest companies in the world namely Microsoft took 17years to roll out Address Space Layout Randomisation in Windows 10, coupled with Intel pursuing speed over security something which is mutually exclusive due to their chip designs, something ARM recognised a long time ago, so is it any surprise that the IEEE standards are where they are today? If you want to get a headups about what exploits are a problem get involved with the IEEE to find out what standards they are trying to improve to solve some hacking problem. The window of opportunity is open as long as the IEEE takes to finalize a standard.
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.
Not if "someone [who] can subvert Digicert" is government/state. In this case they have an easier task as governments directly control DNSSEC signing keys, and subverting Digicert and issuing rogue certs would be visible in Certificate Transparency logs.
Governments directly control the DNSSEC signing keys for their ccTLDs, but at best indirectly control DNSSEC signing keys for some gTLDs. The US government could, for example, use some legal instrument to compel a US-based CA to issue a certificate for an arbitrary domain, and similarly compel a US company like Verisign (who manage the .com gTLD) to change the DNSSEC records for a .com address.
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.
I don't understand how people make this argument with a straight face. Google cannot simply abandon .COM. The most commercially important domains in the western world are all controlled by Five Eyes governments.
Google already do abandon .com for localised search in individual countries, and most people aren't actually typing "google.com" to find the search engine (it's probably a browser setting).
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.
If you think "give up on .COM, .NET, .ORG, .UK, .IO, .CA, .AU, and .NZ" is a reasonable response to this problem, why stop there? Virtually everyone agrees DNSSEC isn't a great protocol; had it been designed in 2010 rather than in 1994, it would for instance take advantage of online-signing, like every modern cryptosystem does. Why not just go all the way to something like NameCoin? You've already given up on, basically, "the Internet" as people know it.
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.
If your threat model includes the threat that Five Eyes governments will try to (legally, or otherwise) commandeer the DNSSEC infrastructure (and, more easily, the CA system) to actively attack users accessing your server, then it is perfectly reasonable to "give up on .COM, .NET, .ORG, .UK, .IO, .CA, .AU, and .NZ". Under such a threat model it would also be prudent to never visit a Five Eyes country, or hold any assets there.
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:
> an attacker between you and your DNS server could determine which sites you are attempting to communicate with just by reading packets on the network.
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.
If you can see that I'm communicating with cloudflare IP, it doesn't tell you very much. There are thousands of websites behind that IP. If you can see that I resolved some specific domain to that IP just before I started to send packets to that IP, you know probably I'm communicating with that specific domain.
"you should fix that front right flat on your car"
"yeah but there is a flat on the front left so what does it matter"
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.
Fair enough, I probably deserve that response, especially since the TLS fix is apparently closer than I thought.
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.
If you're running Firefox Nightly and using DNS over HTTPS or TLS it's now an completely encrypted tunnel as Cloudflare and FireFox have deployed encrypted SNI.
You’re looking at the wrong end of an attack here - it’s true that an attacker targeting you gains very little, ut an attacker targeting the DNS resolver gains knowledge about everyone using that resolver.
I don't think the author of this article is really familiar with its subject. It's certainly not the case that "any security expert you ask will recognize the value of DNSSEC", or that we can all agree that it's a good thing. I'm far from the only security person saying DNSSEC is a very bad thing.
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.
What is your opinion on handshake.org? I am excited about it’s potential even though it has a massive uphill battle to gain adoption. The main reason why I’m excited about it is because it could also be used as a cryptographic identity that’s compatible with the old system.
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.
You're one of the few. And I can't imagine why anyone would want to enroll their personal keys --- SSH, IPSEC, whatever --- into a global PKI. Your VPNs and SSH connections are more secure, objectively, outside of DNSSEC.
Only if you have an out-of-band way of verifying SSH keys. In my experience, 9 out of 10 times that doesn't happen and people just accept a changed SSH key.
To add to that, new protocols are designed not to rely on DNSSEC: MTA-STS for MX records (uses HTTPS), Web Key Directory for OpenPGP keys (uses HTTPS).
Putting user keys in DNS is an obvious mistake: deeply connected to DNS is the idea that the data in DNS is public. It requires heroic attempts like NSEC3 to keep data private and even NSEC3 is not enough. Trying to put list of users (mail addresses) in DNS is a mistake.
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."
When you say "some people don't like DNSSEC", you're sort of dancing around the fact that the people who don't like it are some of the most important organizations on the Internet; to wit: all the major mail providers.
Which is fine. Do I really care about the security of Gmail? Yahoo? Hotmail?
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.
I don't know. Do you ever email people? If so: yes, you do.
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.
I assume that when you say 'virtually none', you are aware that more than 50% of the dot-nl domains (so around 3 million) are DNSSEC signed. Furthermore, more 60% of the DNS queries that reach the servers for the dot-nl zone are from validating resolvers.
One of the nice things about DNSSEC is that it is both optional and it actually works.
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.
And being verifiable this means we don't need to care about how it gets transported to clients, which is a recurring theme in Internet design.
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.
If you're going to argue that implementation difficulties make DNSSEC too much trouble I can respect the argument. To say that it doesn't solve a problem worth solving is strange.
Interrogate the thought more carefully. I understand why your default assumption is that securing DNS records is a good thing. But why is that, really? All sorts of things aren't secured cryptographically --- ARP! IP options! --- and we don't care. The modern Internet was designed with the assumption that the DNS is insecure.
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.
> Had DNSSEC been deployed 5 years ago, Muammar Gaddafi would have controlled BIT.LY’s TLS keys.
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.
This is a little like saying that it would have been fine if Libya had simply been granted a root CA loaded in everyone's trust stores; after all, CT would detect the bad certificates.
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.
No, it’s a little bit like saying that Libya should be granted a root CA that is only accepted for .ly domains and only with appropriate CT records. Which actually seems quite reasonable to me.
Edit: Libya could create a bitly-like service and serve it up at bit.ly right now. What exactly would stop them?
What are my options if I don't want my ISP (and thus the government, which in my case can easily get that information) to easily know which sites I'm visiting and thwart their attempts to block sites using trivial methods — assuming I don't use my ISPs DNS service and use something else? I know that my ISP would have the IP addresses I'm connecting to and also the encrypted traffic (for TLS) to the addresses along with timestamps, my IP address/location, etc., which would/may allow for various inferences to be made.
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?
Tor is probably the appropriate technology for this purpose.
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.
48 comments
[ 3.4 ms ] story [ 111 ms ] threadIn 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.
https://tools.ietf.org/html/draft-zhang-trans-ct-dnssec-03
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:
https://www.namecoin.org/2017/06/22/tor-prop279-release.html
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.
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.
https://www.cloudflare.com/ssl/encrypted-sni/
So with this combo you would be unable to determine which HTTPS sites I am visiting that are hosted on Cloudflare.
https://sockpuppet.org/blog/2015/01/15/against-dnssec/
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.
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.
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.
[0] https://en.wikipedia.org/wiki/DNS_hijacking#Manipulation_by_...
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 :)
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.
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.
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?
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.