This is nonsense, and possibly crossing the border from ignorant nonsense to malicious nonsense.
DNSSEC ensures that received DNS records are signed by an entity authorized to publish changes to the domain. It does not ensure, in any way, that this entity is publishing the right changes. It protects you against man-in-the-middle attacks, but not "hijacking" as usually envisioned. The linked article https://krebsonsecurity.com/2019/02/a-deep-dive-on-the-recen... identifies multiple cases of registrars saying that someone broke into their web interface (either by determining valid account credentials, or finding a flaw in the web interface). DNSSEC is not designed to protect against these attacks. As that article points out, some of the victims did in fact have DNSSEC set up.
As 'tptacek pointed out a few days ago, many .gov and .mil domains have DNSSEC and were nonetheless victims of DNS hijacking attacks. https://news.ycombinator.com/item?id=19180817 The US government is correctly not insisting on additional rollout of DNSSEC.
I myself have been a victim of DNS hijacking: in January 2013, someone hijacked mit.edu and (among other things) redirected the MX records to non-MIT servers. https://thetech.com/2013/01/23/hack-v132-n63 I lost email to my mit.edu address as a result, and if the attacker were interested in targeting me (or targeting MIT account holders in general) they could have triggered password resets by email, etc. They got in because they apparently knew the password for MIT's account at EDUCAUSE, domain registrar or guessed it on the first try. DNSSEC would not have prevented this. The attacker would have simply instructed EDUCAUSE to sign the records, or instructed EDUCAUSE to update the public key to one under the attacker's control.
And, for bonus points, had they done so, they likely would have been able to lock out MIT of regaining control of the domain for longer than it actually took.
As long as domain validation is the standard for getting certs, the security of the DNS system will be part of the security of DNS.
At the moment, DNSSEC is the only off-the-shelf authenticated DNS system. We need that authentication between the DNS servers and the Certificate Authorities.
DNSSEC between the DNS server and hosts doesn't matter much. There are other ways to MitM, and insecure fallback is inevitable.
In the end, the DNS system is what we use for identity management, so it should be authenticated. As the recent attacks have shown, the actual administration of the DNS servers (Registrars) also needs to be secured. That is not DNSSEC's role.
But in our current system, if a registrar is compromised, the system is compromised anyway. I'd love to hear an idea that obviates the need to trust Registrars. Without such an option, I don't think 'this doesn't defend against DNS account hijacking' counts, because nothing defends against DNS account hijacking.
Once someone has that account, you are fucked. HPKP is essentially the only thing that could save you, and that has (rightly) been deprecated.
There is in fact very little evidence that we "need" the authentication provided by DNSSEC. Here we have an illustration of a phenomenon we've seen repeatedly: an attack for which DNSSEC has absolutely no utility, used deceptively as an argument for the necessity of DNSSEC. The same was true of claims that DNSSEC was a necessary response to BGP hijacking a few months ago.
If there were actual routine attacks that DNSSEC was seriously defending against, you don't think its advocates would be sounding their trumpets about them incessantly? Occam's Razor argues emphatically that the attacks DNSSEC deals with aren't occurring.
Meanwhile: if the reason we need DNS security is for certificate issuance, DNSSEC is a stupid way to get that. We can and will create a secure channel directly between CAs and registrars (one such system is RDAP, the upcoming replacement for WHOIS). We also have systems in place that have demonstrably defeated misissuance, most notably certificate transparency, which does not in any way depend on DNSSEC. CAs can and will do multi-perspective DNS lookups, which are valuable (though imperfect) even against the BGP attacks that completely bypass DNSSEC.
The history of Internet network security is largely the history of higher-layer systems routing around the insecurity of DNS; an insecure DNS is practically the premise of Internet security. And throughout that entire history, going all the way back to when I was in high school in the early-mid 1990s, DNSSEC advocates have been trying to foist this boondoggle of a protocol onto us. It was annoying when it was just a bad cryptosystem that was impossible to configure. But now it's a key escrow system as well. Fuck that. DNSSEC is still failing. Let it fail all the way away.
I get it, it’s cool to shit on DNSSEC. But let’s talk about defense in depth. The way you solve account hijacking is two fold. First: authenticate records. Second: don’t trust registrars to produce the contents of records. Reduce registrars to a simple ledger indicating which key to trust for a domain along with the length of the lease. Make people take care of their keys. If a registrar does offer to sign records on an owner’s behalf, maybe don’t use it for security critical services like email.
I don’t think the desire to authenticate data coming from the internet’s global public key-value store is ludicrous.
Let's just secure the perimeter and live in a world of VPNs and negligently open hosts. I'm not strictly arguing that DNSSEC is a good thing. But I do think it makes sense to authenticate data flowing across general networks, no? You're saying the problem isn't a problem because part of the solution is stupid today. I guess it's job security for security professionals to have insecure things floating around that need additional security? At least some people want to solve the problem. The internet as it exists today being engineered around insecure DNS is not a feature. Name one other scenario where there's a preference for no security.
People used to say the same thing about the boot process. Now we have secure boot. Maybe that's just stupid too but I feel a lot better knowing that my hardware is booting verified images than whatever happens to be sitting at some address in unprotected memory (as long as I remain the owner of the key).
> Every useless security product ever pitched has justified its existence with "defense in depth".
Even if this is true it is also shallow, misleading and IMO more of a master suppression technique[0]: even if we accept it as true it doesn't mean the opposite is true (i.e. that everything that is marketed as "defence in depth" is a useless security product.
You're rebutting an argument that I didn't make. What I said was that "defense in depth" is a weak argument. I didn't say that any solution that invokes "defense in depth" is bad. DNSSEC is bad on its own merits.
How does the registrar know which key to trust? There must be some way for the domain owner to indicate their key, and to replace it if they lose it; essentially, a website where you login and upload your key, much like you currently login and configure your records.
Given that just about everyone here recognizes the bad faith shown by ICANN on this issue, it seems to be an act of desperation on their part. Why? They've invested a lot into DNSSEC and are emotionally wrapped up in it, despite better alternatives. And maybe more importantly, if you consider DNS an asset, then its value rises by stuffing more "value" into it such as key escrow. Therefore DNS's principal holders (ICANN, TLDs) would see their asset depreciate if DNSSEC fizzles and dies.
RDAP sounds great, that'll essentially do what I think DNSSEC is for now. I'm going to look into that more.
For it to really help though, DV using DNS needs to stop working. That's going to take a while, but I guess the same goes for convincing all Registrars to use DNSSEC. In that sense, it seems like IANA should be pushing for RDAP.
Certificate Transparency logs are kind of orthogonal to DNSSEC and DV though. The main value in Certificate logs is forcing CAs to act honestly.
CA's not getting accurate DNS records is not completely something the CA's can prevent, because they can't authenticate DNS records. Though certainly, they can do their best by using multi-perspective look-ups and other things.
I still think it's scary that registrars have ultimate power over issuance. They seem like the next weak link after CT logs are widespread enough to defend against rogue CAs. Luckily, it is harder for a registrar you don't use to claim your domain, so it is easier to defend by choosing a registrar you trust.
An other view of the history of Internet network security is largely the history of plain text protocols getting encryption and authentication. As much as some is arguing against the introduction of authentication in DNS, there are a similar push in the opposite direction where people instead want to add encryption.
For now most of that discussion is the two dominating methods to get encryption and authentication between the user and recursive resolver, but there are plenty of good reasons why we want the same standard of security between recursive resolver and authoritative resolver.
> An other view of the history of Internet network security is largely the history of plain text protocols getting encryption and authentication.
Telnet was replaced by ssh, but they're both connection-oriented protocols that create a session between two endpoints. The same is true of the transition from X to X-over-TLS for the various values of X.
DNS isn't really a connection-oriented protocol to begin with and DNSSEC isn't really a protocol at all, it's a collection of DNS records for use in signature verification. Moreover, it's not encryption, only signatures. It doesn't provide privacy protection. The DNS equivalent to the transition to ssh or TLS would be something like DNSCurve, which is a transport protocol and does encrypt the data.
Not entirely. The promise of DNSCurve is that the authoritative servers can use it too. If they do, it can secure the queries between the recursive resolvers and the authoritative servers as well, and inherently provides secure delegation between administrative boundaries when the parent and child domain both use it.
DNS over TLS/HTTPS typically only secures the link between the client and the resolver, and does so at the complexity cost of bringing in all of TLS and its problematic CA system, and HTTP on top of that for DoH. And the proposals to make it work to the authoritative nameservers have it using DANE (i.e. DNSSEC).
TLS could be used in much the same way that a mining truck could be used by a letter courier service. You can, doesn't mean you should.
With DNSCurve, when you have a delegation from one authoritative server to another, the parent domain provides the name of the child domain's nameserver, which encodes its public key. Then you use the public key to communicate with the child nameserver. The key distribution is part of the protocol.
To use TLS, you would either have to rely on the CA system with all its problems (any malicious CA can forge any name and many are operated by potential adversaries), or DANE, and then we're creating a dependency on DNSSEC rather than replacing it. Worse, you have to choose one or the other for everyone or else support both as options and have the worst of both worlds in combined complexity and lowest common denominator security.
The overhead of DoT/DoH is also worse in the recursive case. Between the client and the recursive DNS server, creating a TLS session is expensive but at least then you can keep it active and use it for all your queries. In the recursive case the queries go to/from many different authoritative servers, each with low probability of reusing the connection such that keeping it active long is counterproductive. So you're moving from a single UDP request and reply to a full TCP handshake + TLS handshake for as little as a single query. This adds both computation and latency.
Moreover, the one redeeming quality of DNS over TLS/HTTPS is avoiding interference by middleboxes, which exists almost entirely in the context of client devices on restrictive networks rather than the links between recursive and authoritative DNS servers.
DNS is just as much a connection-oriented protocol as http. It just happens that DNS uses caches a bit more than the web because of "reasons", so we got all those caches called recursive resolves being the default.
An early argument against HTTPS was that you could not use web proxies any more. Today we don't normally talk about that, in part because the caching was moved away from the middle and into the server end.
The discussion around how useful DNSSEC misses the point that what history has shown is that authentication without encryption is like encryption without authentication. We need both and preferable done yesterday.
At the moment, DNSSEC is the only off-the-shelf authenticated DNS system. We need that authentication between the DNS servers and the Certificate Authorities. DNSSEC between the DNS server and hosts doesn't matter much. There are other ways to MitM, and insecure fallback is inevitable.
Your reasoning is of the form, "We need something. This is something. Therefore we need this."
No, actually we don't. We don't need this unless we can demonstrate that it makes things better in the real world, with real problems that people really encounter.
The problem isn't simply that it fails to protect against DNS account hijacking. The problem is that it makes the common problem of DNS account hijacking even worse than it is now. Which means that it makes an existing problem bigger than it is now.
Yes, it also solves another problem. But now we have to look at it as a tradeoff between two problems, decide which is worse, and decide accordingly. Every security professional and network admin that I trust finds the tradeoff obvious, and not in DNSSEC's favor.
Sadly, if you can spoof DNS replies, you can probably strip the DNSSEC records. You need fail-closed systems for security, but fail-closed systems are not user friendly, and thus won't be accepted.
Those don't work if you claim to be a non DNSSEC compliant resolver.
Should clients really fail closed when faced with a non DNSSEC resolver they got from e.g. the starbucks WiFi DHCP? And if they should, do you really think they will? Because users will complain loudly.
To secure against these attacks, registrars and dns hosting providers need to improve the management of the zone. Things like allowing NS, DNSKEY, and DS record updates to be authorized separately from other record management. To limit the general updates to standard DNS records.
This doesn’t fix the problem of course as access can still be gained to the master admin account if it’s credentials have been compromised, which is true about nearly every service on the internet. DNS is no different, except of course that it’s critical to serving traffic to a site.
I agree with the GP in that ICANN is being dishonest in encouraging DNSSEC as a response to hijacked accounts. What they should be pushing for is better security practices, like 2FA, by the registrars and more authorization limited options for limiting the exposure of an account to common updates versus less common more critical ones.
dnscurve and dnscrypt handle a different use case than DNSSEC. DNSSEC allows for the records in a DNS zone to be verified via signatures, also stored in the zone, RRSIGs, against keys also registered in the zone, DNSKEYs, which are pinned to the zone along with the NS records in the parent zone via a record called a DS record.
dnscurve and dnscrypt are in the same space as DNS-over-HTTPS, DoH, and DNS-over-TLS, DoT. What they do is authenticate the dns server (resolver) and also encrypt the channel giving you privacy.
DNSSEC == authenticated records.
dnscurve, dnscrypt, DoH, and DoT == authenticated and encrypted resolutions.
> DNSSEC == authenticated records. dnscurve, dnscrypt, DoH, and DoT == authenticated and encrypted resolutions.
But notice that authenticated resolutions get you authenticated records provided you do them all the way to the root. The root servers on down could support DNSCurve or similar and you could operate recursively using it, or have your trusted recursive resolver do so as you in turn reach it using the same mechanism.
Meanwhile that wouldn't break the cases where you want your DNS server to modify records, e.g. for blocking tracking domains.
Authenticated resolution does not give you authenticated records. You cannot verify that the response between root and your resolver wasn't manipulated or that some DNS Server in the chain is sending malicious responses, even if they had DNSCurve.
If the root was using DNSCurve, a request to the root would be authenticated, and so on all the way down for each domain that uses it. The recursive resolver would have authenticated responses from each authoritative nameserver from the root on down.
The recursive resolver could then provide a different response to the client, but the client could use DNSCurve to authenticate its DNS server as well, so the client only gets malicious responses if it configures a malicious DNS server.
And that would compromise anything. What happens to DNSSEC if the attacker replaces the client's DNSSEC root keys with the attacker's?
DNSCurve doesn't authenticate the records themselves. A malicious DNS Server can provide simply wrong responses and you cannot notice. There is no way to tell if a provider gave you a bad response.
With DNSSEC the DNS Server also has to advertise different keys, which is something you can notice in your resolver and alert too, for example if you already know the key is different via a side channel or you communicate with another resolver and they got a different key.
DNSSEC makes such manipulation obvious and also prevents in-transit tampering. Coupled with DoH/T you get all the benefits of both.
> DNSCurve doesn't authenticate the records themselves. A malicious DNS Server can provide simply wrong responses and you cannot notice. There is no way to tell if a provider gave you a bad response.
Sure there is. You do the recursion yourself and compare the result. If you do this 100% of the time, i.e. run your own recursive resolver, there is no need to even have a third party recursive DNS server that could potentially send malicious responses. If you do it a lower percentage of the time at random, or for specific queries you're expecting interference with, you detect the interference and know not to trust that DNS server anymore.
Comparing keys in DNSSEC is no better than this. If a MITM attacker has altered your root keys, the attacker can forge responses from any DNS server you use, unless you're using something that actually authenticates the recursive resolver (whether DoT/DoH or DNSCurve), at which point you can compare the query responses again and no longer need to compare the keys or use DNSSEC at all.
> DNSSEC makes such manipulation obvious and also prevents in-transit tampering.
Which is one of its flaws. Sometimes you want friendly in-transit tampering. With DNSSEC there is a fixed root of trust that everybody has to follow and nobody can choose for themselves or alter for a specific subset of the tree.
>You do the recursion yourself and compare the result.
I was talking about during recursion. Plus this is what I mentioned in my previous comment. This is about someone injecting responses on the network level and blocking proper communication or even having taken over an IP via BGP hijack, in which case the NS record might point to the correct IP but a malicious DNS server would be responding.
DNSSEC would detect this failure mode.
>Sometimes you want friendly in-transit tampering
In which case you likely have your own PKI to manage HTTPS MitM as well, so it shouldn't be an issue to run DNSSEC.
If the root servers were using DNSCurve then you would distribute their public keys in the same way that you distribute their IP addresses, over some secure side channel such as your operating system's software update mechanism.
Once you have the public keys of the root servers, no one can impersonate the root servers to you without their private keys. The root servers can then securely give you the names of the gTLD nameservers. If they use DNSCurve, their public keys are encoded in the names of the nameservers and you can communicate securely with them as well, and so on down the chain.
Hijacking BGP doesn't allow you to impersonate any of the authoritative servers that have a chain up to the root using DNSCurve without having their private keys. You can also pin the public keys of any nameservers that don't have a chain up to the root for the same benefit for that subtree, e.g. if some gTLDs used DNSCurve but the root didn't, or to use between your clients and your company's authoritative DNS servers for your own domain.
> In which case you likely have your own PKI to manage HTTPS MitM as well, so it shouldn't be an issue to run DNSSEC.
This is regularly not the case. For example, sysadmins regularly map the most common tracking domains to a black hole in the resolver on the local network or local machine without doing any kind of HTTPS MitM.
>For example, people regularly map the most common tracking domains to a black hole in the hosts file for dnsmasq on their internet gateway without doing any kind of HTTPS MitM.
This behaviour doesn't break under DNSSEC; the blackholed domain either blackholes or the resolver fails due to the bad signature and effectively blackholes as well.
>If the root servers were using DNSCurve then you would distribute their public keys in the same way that you distribute their IP addresses, over some secure side channel such as your operating system's software update mechanism. [...]
And what does that gain you over DNSSEC+DoT/H other than being non-standard?
> This behaviour doesn't break under DNSSEC; the blackholed domain either blackholes or the resolver fails due to the bad signature and effectively blackholes as well.
If you give an address that always sends back ICMP unreachable messages, the client fails immediately and continues to load the rest of the page, but DNSSEC proscribes that.
You could refuse to send a response for those names, but then the client has to wait for the timeout. You could send a response with an invalid signature, but then the client should discard it and continue to wait for a valid response, and you still have to wait for the timeout.
There are also circumstances where you want to return a specific address, e.g. so that attempts to send traffic to that address can be monitored, and redirecting the address doesn't work because it could be a shared host using SNI and you don't want to affect every name pointing to that address.
> And what does that gain you over DNSSEC+DoT/H other than being non-standard?
It's simpler, more efficient, lower latency, has less attack surface and can't be used as a DDoS amplification vector.
And if you want something standard, why not standardize on DNSCurve? Using DNSSEC over that is only the sunk cost fallacy.
How would a TLS-using protocol be used as a DDoS amplification vector?
>If you give an address that always sends back ICMP unreachable messages, the client fails immediately and continues to load the rest of the page, but DNSSEC proscribes that.
You can return resolver errors or no data, there is plenty of options for DNS blackholing.
>There are also circumstances where you want to return a specific address, e.g. so that attempts to send traffic to that address can be monitored, and redirecting the address doesn't work because it could be a shared host using SNI and you don't want to affect every name pointing to that address.
You'll need a PKI for that anyway so you can deploy DNSSEC root keys.
> How would a TLS-using protocol be used as a DDoS amplification vector?
Turning off UDP DNS would break everything that still uses it but adding the DNSSEC records makes the UDP responses a DDoS amplification vector even if some clients use TLS.
> You can return resolver errors or no data, there is plenty of options for DNS blackholing.
DNSSEC validates NODATA responses and clients can respond to resolver errors in various ways that amount to more timeouts.
> You'll need a PKI for that anyway so you can deploy DNSSEC root keys.
That's assuming you want to MitM the connection rather than merely log the attempt before dropping it or record it for traffic analysis even if you can't MitM it.
And, of course, one of these is a real problem and is seeing widespread deployment and has a bright future, and the other isn't and has been failing since approximately 1994.
In the DNSSEC case, yes, that's akin to the same thing.
In the other, PGP is both encrypting and authenticating the data, then sending that over untrusted email servers. DoH, DoT, et al, are encrypting the channel, and authenticating the endpoints, but not authenticating the data.
Full DNSSEC eliminates the need to have a trusted cert supplier. You can make your own very and the DNSSEC system will be able to validate you are you and not someone else in the system.
No, "full DNSSEC", in the hypothetical universe in which browsers ever supported DANE, simply moves you from having to trust CA's like LetsEncrypt to having to trust the registrars and the world governments that have (often de jure) control over domain registration. DNSSEC does not eliminate centralized external trust anchors; it depends utterly on them.
† (spoiler: Apple, Google, and Mozilla dabbled with it and then rescinded their support; Mozilla and Google have both stated, Google more formally than Mozilla, that DANE isn't happening)
As long as DV certs exist the registrars are trusted anyways[0]. DNSSEC + DANE, for all its faults, would at least reduce the set of trusted actors by cutting CAs out of the chain.
[0] Yes there's CT to help catch dishonest registrars, but a similar regime could be applied to registrars directly to force transparency around changes to TLSA records.
Adam Langley explains in "Why Not DANE In Browsers" that this is not in fact the case, and that DANE will ultimately just expand the number of trust anchors; you can't even get things narrowed down to just the governments controlling your records.
Further: a mis-issuing CA can be put to death (as happened to the largest CA when Google caught them mis-issuing). You can't revoke a TLD.
Meanwhile, CT actually exists today and is meaningfully combating misissuance, and obviously does not rely on DNSSEC to function.
> Adam Langley explains in "Why Not DANE In Browsers" that this is not in fact the case, and that DANE will ultimately just expand the number of trust anchors
There are two ways that you might wish to use DANE in a web browser: either to block a certificate that would normally be considered valid, or to bless a certificate that would normally be rejected. The first, obviously, requires that DANE information always be obtained—if a lookup failure was ignored, a network attacker with a bad certificate would just simulate a lookup failure. But requiring that browsers always obtain DANE information (or a proof of absence) is nearly implausible
That paragraph does not claim DANE expands the number of trust anchors.
As magila stated, registrars are already a trust anchor for domain validated certificates. Trusting a certificate directly via DANE vs through a domain-validated certificate doesn't change that. It does, however, cut CAs out of the process, which reduces the number of trust anchors.
If you can't use DANE to block certificates that the WebPKI says are valid, then you're stuck trusting both DANE and the CAs. Browsers don't trust DANE today. Ergo, adoption of DANE would expand the number of trust anchors.
Assuming we need to keep backwards compatibility indefinitely that's true, but that still wouldn't expand the number of trust anchors. DANE isn't a new trust anchor, it's just a more direct way of trusting preexisting trust anchors (DNS registrars). Even if you don't use or support DANE you still need to trust the registrars.
No, that is false. DNS registrars do not sign CA certificates and, without DANE, are not trust anchors in the WebPKI. And, of course, with DANE, they would essentially gain that status. This is a plain fact, but you can reason your way to it axiomatically by (again) considering how trust would be rescinded: Google singlehandedly killed the web's largest CA after a misissuance, but obviously cannot do that to .COM in a DANE world.
When your argument starts depending on redefinitions of well-established concepts, that's a sign that you should reconsider it.
I think we are getting mixed up in this thread over multiple senses of the term "trust". One sense is PKI. Ajedi32 is referring to a different type of trust.
Everyone who uses .com must trust the authority for .com, because that registry's name servers are what delegate control of all domain names in the TLD. Every time you resolve a domain name like "example.com", you are relying on the name servers for ".com" to serve correct information.
If the registry was malicious (or if an attacker compromised it), then the registry could easily seize control of any domain name -- it could rescind the delegation and publish whatever DNS records it chooses, including the DNS records necessary to obtain a domain-validated certificate.
It is correct to say that we "trust" TLD authorities because they can do these malicious things, but they commit to behave in a certain way. We trust TLD authorities in the same way that we trust certificate authorities only to issue certificates following a certain process. Both of these actors are capable of fraudulently obtaining certificates: the CA can mis-issue a certificate directly, whereas the TLD can seize a domain's DNS and trivially procure a domain validated certificate (from a legitimate CA).
This is what I believe Ajedi32 means when referring to "trust anchor" (using the term informally). DNSSEC is not adding new trusted entities, but is rather adding PKI around an existing trust relationships: a child DNS zone (e.g. example.com) always needs to trust its parent zone (e.g. the .com TLD). In the PKI sense, I agree that it would be adding new trust anchors, but those trust anchors would simply model preexisting trust relationships that don't use PKI.
On that note, we also need to trust the Internet root name servers that point to the name servers for the TLDs.
Again, this is a redefinition of the concept of a WebPKI trust anchor (or, for that matter, of a "trust anchor" in any PKI; it would be equally confusing to describe the Linux kernel as a "trust anchor" in a secret storage or XML signing or inter-services authentication PKI).
If you want to use an idiosyncratic definition of a term, that's fine --- I won't, but I can at least follow the argument. But what you can't do is say "that citation you provided does not say what you said it does" when it clearly does using the mainstream definition of the term. It's especially fallacious to pull out this semantic argument about a reliable source that generates a surprising conclusion about trust anchors!
DNSSEC adds trust anchors to the Web PKI.
Obviously, I disagree with the argument that we "need" DNSSEC to securely issue certificates, but the rest of this thread adequately captures my rebuttals to that argument.
If you insist on such a narrow definition of the term "trust" then yes you're technically correct. But it also reduces your entire argument into one of semantics; there's no security impact to adding a new "trust anchor" as you're defining the term.
No, sorry, you're not getting away with that argument. We're not debating "trust"; we're debating "trust anchors". "Trust anchor" is a term of art with a specific meaning, and you can't pretend I'm the one trying to exploit a technicality when you've built an argument whose premise is an idiosyncratic redefinition of the term.
Besides that, you were just plain wrong, twice (you doubled down when I showed the quote that refuted your claim). It's fine to be wrong; I'm wrong all the time! But stubbornly refusing to acknowledge when you're plainly incorrect to the extent where you redefine words is not a good look.
Okay, that's fair. You've won the semantic argument, I was wrong to argue that DANE doesn't add new "trust anchors".
The central point of your comment is still completely wrong though. DANE does _not_ add new trusted actors, and has no significant negative security impact.
That's the term magila used in the comment you originally replied to near the start of this thread before you started the whole semantic debate about "trust anchors". Ultimately, trust is something you place in people and organizations, not inanimate cryptographic primitives.
Agreed. Requiring accredited registrars support/enforce 2FA (and preferably hardware OTPs) would be a much more effective response to this, in my opinion.
Maybe it won't do much for you, but for people like me whose governments actively try everything from DNS Cache poisoning to HTTP/HTML injection to censor the internet—DNSSEC would be amazing.
The whole system needs to be on DNSSEC to prevent hijacking. Just because you have a DNSSEC server doesn’t mean anything if the guy down the way can still be made to redirect traffic to a malicious site.
> And, for bonus points, had they done so, they likely would have been able to lock out MIT of regaining control of the domain for longer than it actually took.
Maybe I'm confused about this detail of DNSSEC in which case I retract that claim - I thought it's possible to advertise a false key with a long TTL and use that to prevent people from accepting records from the true key, if they still have the false key cached. If it doesn't work that way (e.g. if all resolvers will update to new keys and accept signatures from them), great.
An attacker could certainly do that, but they could also advertise bogus records (e.g. the MX record in mit.edu's case) with long TTLs so I don't think DNSSEC makes the worst-case recovery time any longer.
The ostensible difference is that they can advertise records that cryptographically lock out corrections, right? (I think this particular critique is mooted by the maximum TTLs mainstream caches will work on). This was Colm Maccarthaigh's scenario on Twitter last week.
I did see Colm's Tweet last week. I'm just not sure what the attacker gains from the lockout being cryptographic, as opposed to being based on old-fashioned DNS caching. If the attacker gets an A record pointing to a bogus IP address cached in a bunch of places, that's just as bad as getting a bogus DNSSEC key cached - either way, users are locked out until the malicious records expire at their resolvers.
DNSSEC makes many things worse, but I don't think this is one.
Yeah, I feel like Paul Wouters also shot this scenario down pretty conclusively, but I'm sort of doing my best to reconstruct what colmmac was talking about and might not be doing the best job of it.
Aha, I think I saw that tweet too and that's where this idea got into my head. I don't know much about the low-level details of DNSSEC so please just ignore that part :)
You may have missed the part of the linked Krebs on Security article where they talked about cases where deployment of DNSSEC _did_ help:
> Woodcock said PCH’s reliance on DNSSEC almost completely blocked that attack, but that it managed to snare email credentials for two employees who were traveling at the time. Those employees’ mobile devices were downloading company email via hotel wireless networks that — as a prerequisite for using the wireless service — forced their devices to use the hotel’s DNS servers, not PCH’s DNNSEC-enabled systems.
> “The two people who did get popped, both were traveling and were on their iPhones, and they had to traverse through captive portals during the hijack period,” Woodcock said. “They had to switch off our name servers to use the captive portal, and during that time the mail clients on their phones checked for new email. Aside from that, DNSSEC saved us from being really, thoroughly owned.”
Obviously DNSSEC won't save you if your account with your domain registrar gets compromised, but there are other situations where it _is_ effective.
FWIW the article states this only applies for specific MITM cases, but yeah, this is kinda bullshit.
If you want to push back against this, find somebody near Kobe, Japan in the next few weeks who can go to this open session [1] and explain the problems, and provide some alternative solutions.
I agree with rocqua that the Registrar needs to have a more active role in securing DNS. I think we need new standards of control between domain owners, registrars, DNS TLDs, and certificate authorities.
I, as a domain owner, should be able to provide signed changes to the Registrar, and to entities further down the chain, so that just because someone gets access to my account on a service provider, they can not change anything without my private key. Delegation and revocation of other keys can also be handled for large organizations (we do that today with DNS).
> I agree with rocqua that the Registrar needs to have a more active role in securing DNS. I think we need new standards of control between domain owners, registrars, DNS TLDs, and certificate authorities.
There are registrars that do take a more active role in securing dns, but they usually charge a bit more. A surprising many companies and even government departments will compare two dns registrars exclusively on the price, and if one cost $10 annually and the other registrar cost $29 then they will pick the $10 version. What they might not be aware is that $9 out of the price is the registry fee, so what they are really comparing is the service that you get from $1 margin vs $20.
Absolutely. It would make more sense for them to require all registrars to offer proper 2FA (i.e. SMS don’t count). This is something they have the authority to do and that would have a meaningful impact on security.
Sadly, on internet today, encryption does not ensure the connection is private for the client. What happens today is a client can connect to a middle server that implements TLS encryption between it and the client, but then forwards the connection unencrypted to the real server. This is an actual service people use, and the client has no way of knowing it.
We as an industry have to stop using passwords. We have to stop using DNS. In this day and age who needs human-readable URLs? People only remember a tiny subset of most URLs anyway. Why not just make everything end-to-end encrypted and stop the stupid feudalism?
DNSSEC ensures that received DNS records are signed by an entity authorized to publish changes to the domain. It does not ensure, in any way, that this entity is publishing the right changes. It protects you against man-in-the-middle attacks, but not "hijacking" as usually envisioned. The linked article https://krebsonsecurity.com/2019/02/a-deep-dive-on-the-recen... identifies multiple cases of registrars saying that someone broke into their web interface (either by determining valid account credentials, or finding a flaw in the web interface). DNSSEC is not designed to protect against these attacks. As that article points out, some of the victims did in fact have DNSSEC set up.
As 'tptacek pointed out a few days ago, many .gov and .mil domains have DNSSEC and were nonetheless victims of DNS hijacking attacks. https://news.ycombinator.com/item?id=19180817 The US government is correctly not insisting on additional rollout of DNSSEC.
I myself have been a victim of DNS hijacking: in January 2013, someone hijacked mit.edu and (among other things) redirected the MX records to non-MIT servers. https://thetech.com/2013/01/23/hack-v132-n63 I lost email to my mit.edu address as a result, and if the attacker were interested in targeting me (or targeting MIT account holders in general) they could have triggered password resets by email, etc. They got in because they apparently knew the password for MIT's account at EDUCAUSE, domain registrar or guessed it on the first try. DNSSEC would not have prevented this. The attacker would have simply instructed EDUCAUSE to sign the records, or instructed EDUCAUSE to update the public key to one under the attacker's control.
And, for bonus points, had they done so, they likely would have been able to lock out MIT of regaining control of the domain for longer than it actually took.