On Mon, 8 Mar 2010, Nicholas Weaver wrote:
If your ISP is acting as a MitM on DNS, its acting as a MitM on everything, so DNSSEC buys you f-all if you are using it for A records, because any app using that A record either doesn't trust the net or is trivially p0owned by the ISP.
If I detect an in-path attacker, I can choose to disconnect from that network. That is not "buying f-all". It's useful to know when you are under attack.
DNSSEC is ONLY useful for things like TXT and CERT records fetched by a DNSSEC aware cryptographic application, and that would require a valid signature chain from the root(s) of trust (either preconfigured or on a path from the signed root) validated on the client, so an imitation a.root-servers.net won't matter, as it won't be able to provide improper data.
I understand that :P
So in your example, root-servers.net doesn't need to be signed, and buys no increase in trust WHETHER IT IS SIGNED OR NOT, because even if it IS signed, that coveys no value about the results returned from it, because the signatures are not along the trust heirarchy for DNSSEC, which follows the name path, not the lookup path.
If it was signed (along with .net) or via DLV or manual trust anchor, again I could tell I am under attack and disconnect from the rogue network. There is a use for that. Though I agree with people who say this is better done when a full path of trust from the root down is in place to avoid more manual configuration.
[1] And this is why I want DNSSEC: it IS a PKI and should be used as such, but one with a much cleaner trust path than the SSL-model PKI, and without adding any NEW trust paths to the system as this is the same trust path needed for normal DNS.
No need to preach to the choir. We were the ones (ab)using KEY records for IPSEC-OE.
[2] I really don't like DNSSEC's reliance on the recursive resolver to do signature validations, because there really is no right answer for what the recursive resolver should do on cryptographic failures (contrast with the client where there are good answers).
That problem never goes away, see how browsers handle cert failures....
But if the recursive resolver IS validating DNSSEC, it MUST ONLY validate the path of trust for the names requested by the client, simply to minimize spurious and irrelevant cryptographic failures. If the recursive resolver is validating the signatures of root-servers.net for internal use, it is doing it wrong: something which reduces reliability but doesn't increase security.
I don't agree with your "in path" view. If I need to validate a nameserver ns.foo.bar., then yes it needs to attempt to validate the path "." -> "bar." -> "foo.bar." -> "ns.foo.bar.". Or instead of "validate", at least needs to confirm "not verifiably bogus" in the absense of DNSSEC for certain parts if the tree. Paul _______________________________________________ DNSOP mailing list [email protected] https://www.ietf.org/mailman/listinfo/dnsop
