Hacker News Reader

Comment by tptacek | Hacker News Reader

I read this thing so you don't have to. Here's a summary of what I believe this person's arguments to be. If I've failed to be charitable enough, please do call me out for that.

1. With DNSSEC, SPF, DKIM, and DMARC enabled, email is secure enough to authenticate requests for TLS certificates. Without DNSSEC, it isn't.

2. DNSSEC zone owners control their keys, so DNSSEC doesn't imply that the DNS roots control keys.

3. There is nothing wrong with older cryptosystems and anyways, DNSSEC supports elliptic curve now.

4. The code to make DNSSEC deployable is underway and so it's not valid to suggest that it's too expensive to support.

5. All that's required of DNSSEC deployers is to generate a couple of DNS records, and so it can't be expensive to to deploy.

6. It's specious to criticize DNSSEC for only securing server-server transactions and not browser-server DNS lookups.

7. Nobody ever said DNSSEC would provide end-to-end encryption. DNSSEC reveals hostnames now, but there's something called NSEC5 that's going to make that better.

8. Nobody ever said DNSSEC was going to provide end-to-end security so it's not valid to criticize DNSSEC for not doing that.

9. DNSSEC isn't a replacement for the CA system, but rather a security improvement for DNS, so comparisons to TLS and CA aren't valid.

View on HN

Well, allow me to retort:

1. SMTP email isn't end-to-end secure with DNSSEC, SPF, DKIM, and DMARC. It isn't even close. It is unsafe to authenticate CA certificate requests via email before DNSSEC and remains so after DNSSEC. SMTP is insecure. Making it secure is the biggest problem in Internet cryptography and we aren't anywhere near solving it. If domain-validated certificates scare you, the solution is to eliminate DV certs.

2. The roots control delegations. The keys you store in your zone don't matter if surveillance targets never see them, because the government-controlled roots switch delegations to zones they control. DNSSEC is a PKI controlled by NSA and GCHQ. That is literally what it is is.

3. DNSSEC is 90s cryptography. 90s cryptography has been discredited. The DNSSEC roots use an archaic flavor of RSA. ECC DNSSEC records break zillions of deployed implementations. The flavor of ECC that DNSSEC supports is also archaic. This stuff is in the FAQ for the post they're rebutting.

4. The phrase "good money after bad" comes to mind.

5. Here is a list of major DNSSEC outages. DNSSEC reliability is komedy gold:

http://ianix.com/pub/dnssec-outages.html

6. No it's not.

7. 7 years ago, this argument would have been written "DNSSEC reveals hostnames now, but there's something called NSEC3 that's going to make that better".

8. There is a finite amount of money and energy to be spent on cryptographically improving core Internet infrastructure, and the many deficiencies of DNSSEC are why virtually nobody credible in the cryptographic engineering community thinks DNSSEC is a good use of that money. We can't spend tens of millions of dollars forklifting in a baroque new cryptosystem that doesn't actually encrypt anything.

9. The sole important application for DNSSEC is storage of TLS certificates.

1. Why? An unqualified blanket statement does not prove anything. SPF, DKIM, DMARC provide strong cryptographical ties to a specific, real, and verified account holder. DNSSEC provides domain level certification. So, with all four items, there is a very strong assurance level of the validity of the email account holder. Do you honestly disagree?

2. Can DNSSEC be re-directed to incorrect public keys? Sure. But DNS can be pointed anywhere anyway. DNSSEC does no extra damage. And exploitation of DNSSEC enabled domain records is very easily discoverable by the domain holder, since the public key will no longer match the domain's private key... which is still very much in the domain owner's control.

3. Much of cryptography dates to the 1950s. This '90s cryptography stuff is pure nonsense.

4. Only if you don't value the hard work by many smart people over a long time.

5. OK. Denial of service is a bad thing. If you have a worldwide network, you are going to have denial of service. Mitigation is possible... maybe instead of throwing out other people's work, some resources could be used to improve what's already out there... ah... but then back #4.

6. Yes it is.

7. Revealing hostnames is only a problem if a domain is seeking to hide hosts. So, this particular issue is domain level dependent -- why not let a domain owner speak for him/her self?

8. Again with the 'old' is bad 'new' is better? Got anything else?

9. Wrong. SSH public keys, Email public keys, DKIM public keys... check your email headers from Google... they all have "unprotected key" because Google doesn't use DNSSEC -- the large provider host hiding problem is most likely why.

However, for a small domain, DNSSEC is terrific.

1. Because SMTP email transmits unencrypted messages through a series of insecure relay servers. SMTP is insecure. The protocols you mentioned are band-aids that do not result in SMTP being end-to-end secure. But that's what SMTP needs to be if all of Internet security is going to rely on it to authenticate keys.

2. The point of argument #2 is that the government's ability to poison the DNS makes it unsuitable for storing end-user keys, which, no matter what the DNSSEC deployment goal you have in mind is, is the core function of DNSSEC.

3. Elliptic curve cryptography is from the 1980s. Secure elliptic curve functions take you to the early 2000s. Authenticated encryption functions are late 90s early 2000s. The first error oracle attack was published in the early 2000s; practically all cryptography designed prior to that was designed ignorant to the concept of an error oracle. I could go on.

4. That's not an argument.

5. The problem with DNSSEC isn't that it makes DDoS attackers easier, although it does. The problem is DNSSEC spontaneously kills sites because it is calamitously easy to screw up, because it is very complicated.

6. That's not an argument either.

7. Virtually every Fortune 500 company on the Internet currently depends on some way on hidden hostnames. You more or less admit that this is a real problem when you cite NSEC5 as a step forward; it would be unnecessary if you were right that hidden hostnames were unimportant.

8. Non sequitur.

9. I'm not smart enough to understand what this argument means.

> 9. I'm not smart enough to understand what this argument means.

Thomas, I _think_ you are replying to this:

> 9. Wrong. SSH public keys, Email public keys, DKIM public keys... check your email headers from Google... they all have "unprotected key" because Google doesn't use DNSSEC -- the large provider host hiding problem is most likely why.

With which I'll agree with jocluteseh that the value DNSSEC can bring is far larger than only TLS certificates - although I agree with you that protection of TLS certs is one value it brings.

There are people using DNS/DNSSEC to secure the storage of SSH public keys, of PGP public keys and other similar public keys.

People are putting those keys in DNS and then using DNSSEC to ensure that someone retrieving those keys and performing DNSSEC validation can be sure they are getting the correct keys associated with that domain.

Why on earth would anyone store SSH keys in a PKI controlled by NSA and GCHQ? How does that not make the argument against DNSSEC even stronger?

To expand on this. If you store your public SSH key in DNSSEC, I'm assuming that the use-case is either:

1. Pull the public key from DNS to add to ~/.ssh/authorized_keys

2. Implement an sshd runtime that checks the DNS record rather then (or in addition to) ~/.ssh/authorized_keys

Sure, it's "just" the public key so you're not providing the private key to the world-at-large, but if the NSA controls DNSSEC, then they can change the public key to one that is paired with a private key that they control. Now they have access to all systems that the public key could access. This is basically adding DNSSEC as an attack vector to your ~/.ssh/authorized_keys file, which seems like a bad idea.

Please correct me if I'm missing something about how DNSSEC and SSH keys would be used together.

The idea would be to enable you to verify the public key of a server to which you are connecting for the first time. RFC 4255 outlines this use case:

http://tools.ietf.org/html/rfc4255

When you first connect and get the SSH fingerprint, how many people truly validate through some other mechanism that this is the correct public key to use for some system? (I have on some systems but I know I have just accepted the public key on other systems.)

The idea is to use DNSSEC and the SSHFP record to provide a mechanism to validate the SSH public key.

Do note this is not a new idea. This RFC was published back in 2006.

The NSA can take any one of their trusted root keys, which I don't think it would be healthy to doubt they are in possession of, and sign a certificate today.

With DNSSEC, they'd have to subvert the entire DNS infrastructure, signed from the top all the way down to the particular domain they want to falsify. But it is somehow this infrastructure you wish to label "NSA controlled"?

What difference does it make whether the program they run to carry out this attack is 100 lines long or 400 lines long? DNSSEC gives NSA and GCHQ this level of control by design. It is a PKI, based on delegations from a root, where the top of the tree is literally controlled by the US and UK governments.

The difference is not in the complexity of the code, but the magnitude of the attack. You would need to subvert every DNS request from a certain client, for the duration of the TTL of all signature points. (Exactly how much harder it is depends on the circumstances, but a travelling target would be even harder than a well known stationary one, even if you control large parts of Internet infrastructure and is willing to use it.)

But that's not the point. The only point is that between it and the SSL CA infrastructure, the latter is the one NSA has more control over and a much easier time generating certificates for, so the labelling the former "NSA controlled" is slightly disingenious.

You don't like the CA system. I don't either. I go farther, and say "it's a very bad idea to replace the CA system with another hierarchical PKI the top of which is controlled be NSA and GCHQ". I'm not sure I understand your rebuttal to that point.

Because it is not "controlled" by the NSA in any meaningful way (with emphasis on meaningful).

Any such argument would be valid for pretty any global PKI system, if the argument is that they control important parts of the Internet infrastructure. The SSL CA system is even more controlled by the NSA as DNSSEC is.

DNSSEC is much harder to circumvent than the SSL CA system, no matter how you look at it.

So I do not mean to refute that the NSA controls the Internet, the CA system, and DNSSEC (even if I don't believe that's an accurate description). It is simply not a meaningful discussion to have. Even if the NSA can break the Internet, there are other use cases and it still carries great value for everyone.

It's not controlled by NSA? The largest nodes in the tree are literally controlled by them. The corporations that control the root are domiciled in the US. Google's remedy for misuse of any of those zones is to stop being GOOGLE.COM. This is a silly discussion.

> It's not controlled by NSA? The largest nodes in the tree are literally controlled by them.

Perhaps I should thank you, Thomas, for continuing to beat this drum... because it shows extremely clearly how we need to educate more people and be MUCH more clear about exactly how the keys at the root of DNSSEC are maintained. If people fully understand the process, and how it was designed to NOT allow attackers in this way, we could spend our time on much more productive discussions. (Granted, documents such as https://www.iana.org/dnssec/icann-dps.txt do NOT make for friendly reading.)

Thank you for pointing out the work that needs to be done.

The idea that process and policy addresses this problem is wishful! By design and by law, the most popular and important TLDs are controlled by governments, and, particularly, the US and UK governments. The most popular generic TLD after COM/NET/ORG is IO, which is controlled by the world's most unhinged signals intelligence agency.

You are advocating for a PKI that is literally shrink-wrapped around government-controlled namespaces. For a security protocol on the global Internet, that's an utterly unforced error. It boggles my mind that anyone had ever considered it, and I am thankful that it is a dead letter now.

But if NSA controls DNS, by extension they control the TLS CA tree as well. Because domain validated certificates is what everyone relies on for security.

Again, that's the point. You keep pointing out that DNSSEC is somehow government controlled, when what you really mean is the entirety of DNS and CAs put together are, and not specifically just DNSSEC. That doesn't make for a constructive discussion since there is no context of an alternative system. Status quo still leaves us with easily falsified domain validated certificates.

I can agree for the sake of discussion that the DNS and CA system is under government control. So against an intelligence organization with unlimited resources anything built on DNS or certificates would fall, so DNSSEC wouldn't help you there. But against every other attacker in the world it absolutely would (while making the attacks it can't defend against easier to detect).

tptacek:

> Why on earth would anyone store SSH keys in a PKI controlled by NSA and GCHQ? How does that not make the argument against DNSSEC even stronger?

Please remind me again how the NSA/GCHQ can subvert my domain at example.com without anyone else in the chain noticing that?

What makes you think anyone is going to notice? DNS is a distributed system. The NSA is a byzantine attacker. There is no instantaneous convergence on a single answer; CAP applies; a byzantine DNS attacker can deliberately introduce inconsistent answers. Virtually none of the DNS resolvers in the world also function as inconsistent-answer detectors.

There's this weird presumption among DNSSEC advocates that DNS is somehow resilient against targeted attacks (you see it every time an argument lands on "but people will notice that"). No. Not only is that not true, but it's even less true than other protocols where we know that to be true; for instance, BGP4 is also not resilient against byzantine failures, but at least BGP4 updates propagate (BGP4 is like a "PUSH" system in that regard, where DNS is "PULL").

What's even funnier about this "people will notice" objection is that people routinely notice corruption at certificate authorities... and nothing happens to those CAs. Compared to the DNS roots, CAs are trivial to blacklist.

Nobody is going to notice targeted attacks on DNS, but even if they did, nothing will happen; there is no disincentive to those attacks for the attackers.

Thomas,

I perform DNSSEC validation on the edge of my home office network. All my devices use my DNSSEC-validating DNS resolver on my network server-gateway.

That resolver is going to check the DNSSEC chain of trust using DS records all the way up to the root of DNS.

If I get back a signed record for www.example.com (meaning an RRSIG), my DNS resolver is going to validate the signatures back up to the root of DNS.

If the signatures don't validate, it's going to give me a SERVFAIL and prevent me from going to whatever site I'm trying to get to.

If the NSA/GCHQ/whomever wanted to redirect me to another site under their control, they could try to send me the record with a valid RRSIG from their own DNSKEY. My resolver is now going to go to .COM (for example.com) and pull the DS record for "example.com". If the DNSKEY and DS don't match, I'm going to get a SERVFAIL and won't get to the site.

Now, the attacker could try to send me their own DS record for the .COM domain... but that's going to be signed by the .COM's DNSKEY ... which again I suppose the attacker could try to send me a substitute.

But now my resolver is going to pull a DS record from the root of DNS for the .COM TLD. That DS record will be signed with the DNSKEY of the root. My resolver is going to validate that signed DS record and compare it with the DNSKEY for .COM. If they don't match, I'm going to get a SERVFAIL.

Now I guess in theory the attacker could try to send me a DS record for the .COM TLD that is signed by their own key... but here's the thing - my local resolver is already pre-loaded with the public key of the root zone as the trust anchor. So it's not going to trust anyone else's records that purport to be the root zone if the signatures don't match the local trust anchor.

So how does the NSA/GCHQ/etc. carry out this attack to redirect me to another site?

I don't understand the point you're trying to make. In this case, you're talking about a zone (COM) the USG explicitly controls. They don't need to spoof the delegation from the root to COM, or the anchor key for the root itself.

The NSA attack assumes an NSA level attacker has access to the root zone's (or someone else in the chain's) private key.

The NSA can then send a key for the .COM TLD that's valid, according to your pre-loaded local resolver, and they can also send a seemingly valid record for example.com.

The CA mechanism used for TLS has the same issue. It's not just theoretical either, Gmail and other Google domains had fake certificates that passed validation issued by CNNIC, China's Internet authority, which was discovered earlier this year.

But here's the thing - the root zone's private key for DNSSEC is not in one place. It is spread across a number of smart cards carried by a variety of individuals spread around the world - specifically so that it could not be compromised by governments or others.

You can see for yourself exactly what kind of process takes place to use the root key to generate new Zone Signing Keys (ZSKs) every 3 months at the IANA key ceremonies: https://www.iana.org/dnssec/ceremonies

It would be an extremely difficult process for an intelligence agency to subvert, even one with essentially limitless resources.

But domains under .COM are exactly as trustworthy as Verisign, right? The root key signing ceremonies are just theater, right?

> The CA mechanism used for TLS has the same issue. It's not just theoretical either...

Exactly. Which is why so many of us are looking for ways to add an additional layer of trust to the CA system used for TLS.

One such mechanism is to use DANE and DNSSEC as an additional mechanism for trust.

tptacek:

> I don't understand the point you're trying to make.

I am trying to understand how the attack you say is possible truly is possible.

> In this case, you're talking about a zone (COM) the USG explicitly controls. They don't need to spoof the delegation from the root to COM, or the anchor key for the root itself.

Verisign operates the .COM TLD registry and has documented in excruciating detail how they handle the security of DNSSEC key material: https://www.verisigninc.com/assets/tld-gtld-zone-v1.2.pdf

Is your assertion that the NSA would order Verisign to bypass those controls and make a change to a DS record (and associated NS records) to redirect people to another site?

If so, how would they do that for just me? It would have to be a much larger redirection of people.

First, Verisign operates the .COM TLD at the pleasure of the US government.

Second, if "just trust Verisign" is enough, we're done: just have the browsers only allow Verisign as the TLS CA for .COM names.

to tptacek's point - an attacker doesn't need to change the root zone. All they need is the root key. (This argument could be equally made of the CA system.)

Then they can sign anything they like, anytime they like, and only for some small targeted set of the population - and for DNSSEC, that's ONLY if you're checking it anyway. (and if you don't control your recursive resolver or patch your browser, tough cookies). @danyork your edge checking is great.. so I presume you never bring your laptop to a coffee shop. ;)

Let's not be naive.. as far as root keys go, Verisign is a big company and will promptly hand over any and all keys upon receipt of an NSL or court order and probably just an administrative subpoena. That's how you win and keep massive, government-mandated monopolies to run the world.

(To be fair, it's not Verisign's fault that the entire CA system is broken. Oh, wait, actually.. it's exactly Verisign's fault. https://en.wikipedia.org/wiki/Verisign#History )

Let's be clear, though, the root of DNSSEC is NOT handled like the root of any CA system. The process of obtaining the root private key is not something where you just break into some system and grab a file somewhere.

The root zone's private key is actually distribute across a set of smart cards possessed by Trusted Community Representatives (TCRs - people like you and me within the Internet technical community) - some number of whom get together periodically in "key ceremonies" to perform actions that require the root KSK, such as the generation of new Zone Signing Keys (ZSKs) every 3 months in what are called "key ceremonies" - https://www.iana.org/dnssec/ceremonies

The entire process of protecting the root zone's key material are documented at length in what is called a DNSSEC Practice Statement: https://www.iana.org/dnssec/icann-dps.txt

Again, the DNSSEC root zone management is EXTREMELY different from that of the CA system. It was designed to be much more secure and to not allow the kind of penetration we're seeing with the CA system.

I think what tptacek is hinting at is that a nation state could forge roots with their own certificates, creating a separate chain of trust. Given that your internet enabled device does not likely have an DNSSEC validating resolver (with uncompromising trust anchors for the roots) operating on it it's still possible for your device to receive forged responses.

He knows that; he's saying, if GCHQ did that to tamper with a key stored for a .IO name, the world would notice, because they'd all get that poisoned key.

But that's not actually how DNS works.

If your Internet-enabled device doesn't have a DNSSEC-validating resolver (with solid trust anchors for the root zone), then this entire conversation is irrelevant.

If your Internet-enable device does have a DNSSEC-validating resolver either on the device or within an acceptable zone or risk[1] then the chain of trust back up to the root zone of DNS will mean that I will notice a substitution and get a SERVFAIL. It may mean that the attacker could DoS me and prevent me from going to a site, but I don't see where I would wind up on the bogus site.

[1] For example, I have a DNSSEC-validating resolver on the edge of my home network. Yes, an attacker could still compromise my home network and send me forged responses. I consider that less likely and am willing to take that risk.

1.a.1 I think this is your main fault. You are assuming that end-to-end encrypted message content is equatable to 'insecure' SMTP. The clear text or encrypted content of an email message has nothing to do with validating that an email account belongs to a domain and is valid.

SPF validates that the email account holder is valid.

DKIM signs the message and provides a body hash which is validated against the public key in DNS.

DMARC allows the domain owner to say that the message should trashed or passed.

And DNSSEC allows the DNS root to say that the sending domain is the sending domain.

So -- I repeat -- with SPF, DKIM, DMARC, and DNSSEC email validated CA certificates are quite secure.

And, yet, you are unwilling to admit this...

I suggest you read the DKIM RFCs, particularly RFC5585

"2.3. Establishing Message Validity

Though man-in-the-middle attacks are historically rare in email, it is nevertheless theoretically possible for a message to be modified during transit. An interesting side effect of the cryptographic method used by DKIM is that it is possible to be certain that a signed message (or, if l= is used, the signed portion of a message) has not been modified between the time of signing and the time of verifying. If it has been changed in any way, then the message will not be verified successfully with DKIM."

While I don't purport myself to be a crypto expert, you can't cite an RFC of a protocol as "proof" that something is secure. For example, if people come up with attacks against DKIM after the RFC is created, they don't issue an errata on the RFC listing all possible attacks.

> DKIM signs the message and provides a body hash which is validated against the public key in DNS

And how do you make sure the public key is correct then ? Well, just use DNSSEC !

Well, about #2, people are defending the status quo (where any governemnt anywhere on the world can compromisse a site's key) by arguing that with DNSSEC there'll always be one government able to compromisse any site's key. Calling that a falacious argument is too charitable, it's an outright lie (and I wonder why that piece of propaganda is so pervasive).

About #3 the article simply points that there's nothing wrong with DNSSEC, unless you choose to use bad crypto algorithms. Guess what, any cryptosystem works the same way, TLS included.

About #6, yes, it's specious to criticize DNSSEC because browsers choosed to not support it (unless you are talking from the point of view of a site master wondering how you'll configure your host today - but even then, that's not a valid criticism of the algorithm, it's just reason to not deploy it now).

About #8, yes, that's not valid. DANE is the main end-to-end encryption algorithm that used DNSSEC, so one must either criticize DANE (if able) or shut-up.

Anyway, what a badly formated page. Points #1, 4, 5 and 7 are flaws. Point #7 is a big flaw, and don't hold your breath waiting for it to be solved. I'd say about point #9 is that DNSSEC is exactly a less broken CA system. I can't see where the author is going...

Fixed formatting a little here: http://shortText.com/6308c7af

> I'd say about point #9 is that DNSSEC is exactly a less broken CA system.

I'd say DNSSEC is more broken than the current CA system. At least with the current system you can more or less choose a CA to trust (or, more interestingly, a bunch of CAs), that you can change anytime you want. The only thing preventing you to do it is the lack of tools to actually do it, which is why tools such as TACK/HPKP, or Convergence/Perspectives, are needed.

With DNSSEC, there is only one realistic root ever possible (call it ICANN or NSA as you want, that's yet another problem)

> At least with the current system you can more or less choose a CA to trust

Blind illusion. You must trust all of them. Any of them can attest somebody is you any time they want.

The good thing about DNSSEC is exactly that it only has one root. And people can pin second and third level domains, completely escaping it - for some other org, controlled by some other agency, but one can choose what agency to submit their identity.

Reply on news.ycombinator.com