Despite proposed solutions, DNS security issues remain(hpe.com)
hpe.com
Despite proposed solutions, DNS security issues remain
https://www.hpe.com/us/en/insights/articles/dns-security-still-an-issue-1810.html
4 comments
> 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.
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.
[deleted]
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.
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?
Edit: Libya could create a bitly-like service and serve it up at bit.ly right now. What exactly would stop them?
[deleted]
> 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.
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.
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.
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.
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.
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).
Even old GnuPG deprecates DNS based key lookup: https://lists.gnupg.org/pipermail/gnupg-users/2018-October/0...
Even old GnuPG deprecates DNS based key lookup: https://lists.gnupg.org/pipermail/gnupg-users/2018-October/0...
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."
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.
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.
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.
I do not care about the thousands of European domains that are signed because domain hosting firms automatically enable it and sign zones for their customers, and neither should you, since that is obviously 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.
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.
It is important, because it is very important to have production traffic.
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.
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.
I flat-out don't understand what argument you're trying to make here. My response to your claim that DNSSEC is widespread because of signed .NL domains was simple: that's because registrars in .NL do that for zones automatically, holding the keys themselves. That's simply theater.
Not sure. Malicious ISP can forge DNS answers [0], the purpose of DNSSEC is to catch that.
[0] https://en.wikipedia.org/wiki/DNS_hijacking#Manipulation_by_...
[0] https://en.wikipedia.org/wiki/DNS_hijacking#Manipulation_by_...
False. DoH, DNS over TLS, and DNSCrypt/DNSCurve address that problem. DNSSEC does not.
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.
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.
> Google's public resolvers have been validating DNSSEC for quite a long time
Quad9 also provides DNSSEC validation on our primary resolvers. Better for you privacy :)
Quad9 also provides DNSSEC validation on our primary resolvers. Better for you privacy :)
But you don't care at all about confidentiality?
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.
Interrogate the thought more carefully.
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 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.
Like SPF? Or DKIM?
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.
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.
What about SPF and DKIM? Virtually none of the world's SPF and DKIM records are signed with DNSSEC.
You said:
> 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.
> 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 don't understand your argument. Again, we have SPF and DKIM now, and neither rely on DNSSEC, which is good, because virtually nobody uses DNSSEC. You absolutely do need SPF and DKIM configured to be a mail sender; the Internet does rely on those. But you do not need DNSSEC to do that, and nobody cares if you do or don't.
And the security is weaker than it should be because the SPF, etc records are unauthenticated.
That's not how security works. In the real world, security is in part a resource allocation problem. We spend resources to raise the cost of an attack over the threshold a model attacker would pay. There is a reason nobody gives enough of a shit to sign SPF records, and you can start to see it by taking the time to track down all the incident reports where someone exploited cache poisoning to override SPF.
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?
P.S.: I read the related FAQ on sockpuppet.org.
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.
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.
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.
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.
At least it's an ethos.
> 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.
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.
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.
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.
Currently, I can also just look at the packets you are sending to that Cloudflare IP and read the domain you're asking for.
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.
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://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.
"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.
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.
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 talking about SNI records in TLS handshake, it'll be fixed soon.
[deleted]
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.
Prove me wrong!
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!
> As long as DNS is insecure, Security Services can intercept and reroute IP addresses (...)
> (...) 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?
> (...) 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?
FWIW, this is the attack that DNSSEC is meant to prevent.
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.
https://tools.ietf.org/html/draft-zhang-trans-ct-dnssec-03
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
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.
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.
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:
https://www.namecoin.org/2017/06/22/tor-prop279-release.html
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
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.