Discuss mailing list

[coyo AT darkdna.net]

My understanding of how DANE/DNSSEC actually works is somewhat 
rudimentary, but the basic premise is pretty much the same as CA-based 
PKI, in that you have trust anchors, a list of ultimately trusted root 
certs that form the top level of trust, and then a chain of trust.

In DANE/DNSSEC, the root certs authenticate the root DNS zone, and each 
subdomain of the root zone is signed by one of the set of root certs. 
These certs are ultimately trusted, and you can import an ultimately 
trusted root cert to, for example, have a non-standard top level domain 
(TLD). .fur, for example, or perhaps .furry. you need a root zone cert 
that authenticates that .furry is authoritatively governed by a set of 
DNS nameservers serving that TLD, which in turn sign certs for any 
subdomains that that zone contains, which could be many.

In other words, DANE/DNSSEC has the same basic model as TLS CA PKI, 
except the DNS heirarchy performs the role of the root CAs, instead. 
Since the same basic model is used, and anyone can import root CAs, 
potentially for perfectly legitimate purposes, it shares the same 
weaknesses as the TLS CA-based PKI.

If a combination of poisoned routers performing IP-level redirection, IP 
masqurading with public IP addresses to redirect traffic to servers that 
don't actually have those IP addresses truly allocated to them, or 
confederate poisoned DNS servers...

Take for example that clients are configured to use 8.8.8.8 and 8.8.4.4 
as their DNS servers. the gateway router has been compromised, and 
forwards any traffic destined for those IP addresses down a GRE tunnel 
or something to another confederate router, which then forwards the DNS 
ports to confederate DNS nameservers.

The client can't really know the difference, IF the client resolver has 
one or more ultimately trusted root zone certs that sign the .com zone, 
and have the google subdomain pointing to the confederate nameservers as 
authoriative. This means those nameservers can use poisoned DANE to 
falsely authenticate entities as having legitimate authentication when 
in fact the client is being subverted.

What this means is that even if DANE is used, it still uses the same 
basic model, and suffers the same weaknesses. My question is, assuming I 
have legitimate or just experimental/educational reasons to do something 
like this, is there anything I'm missing in terms of how to execute such 
a feat?

My comprehension of how exactly DNSSEC and DANE work is admittedly 
lacking.

Any protips, advice, comments or further information would be greatly 
appreciated, and thank you in advance for your time, contributions and 
patience.