Hacker News Reader

Comment by danyork | Hacker News Reader

> 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.

View on HN

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.

Reply on news.ycombinator.com