On Mar 8, 2010, at 7:27 AM, Paul Wouters wrote: > On Mon, 8 Mar 2010, Joe Abley wrote: > >> Our[*] reasoning so far with respect to signing ROOT-SERVERS.NET can I think >> be paraphrased as follows: >> >> - if we sign ROOT-SERVERS.NET it will trigger large responses (the RRSIGs >> over the A and AAAA RRSets) which is a potential disadvantage > > Is it? Is DNSSEC that bad then? Why did we design it that way? > >> - however, since the root zone is signed, validators can already tell when >> they are talking to a root server that serves bogus information > > How does that work without ROOT-SERVERS.NET being signed with a known trust > anchor? > How does my validating laptop know that the curent wifi is not spoofing > a.ROOT-SERVERS.NET to some local IP?
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. 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. 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. Remember, DNSSEC is a PKI, with only one path of trust which matches the name path (so, for *.foo.bar.com, the trust path is foo.bar.com, bar.com, .com, ., either to a signed root, a signed TLD, or a trust anchor configured for either bar.com or foo.bar.com) [1]. You MUST be able to validate along the path (the transitive trust of a PKI), but you ONLY need to validate along the path (the limited trust of a PKI). Thus although root-servers.net is a domain involved in the resolution of anything for *.foo.bar.com (its on the resolution path), it is not on the trust path, so whether it is signed or not has no impact on whether the chain up will validate cryptographically. QED: Signing root-servers.net should be done for completeness, but only AFTER .net is signed, because really, its a signature path that doesn't actually matter and SHOULDN'T actually be validated for normal lookups [2], but only when the values are directly requested by a cilent! [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. [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). 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. _______________________________________________ DNSOP mailing list [email protected] https://www.ietf.org/mailman/listinfo/dnsop
