4 ms·
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.
by danyork 12y ago
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?
- tptacek 12y agoI 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.
- fragmede 12y agoThe 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.
- danyork 12y agoBut 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 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.
- tptacek 12y agoBut domains under .COM are exactly as trustworthy as Verisign, right? The root key signing ceremonies are just theater, right?
- danyork 12y ago> 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.