On Mar 8, 2010, at 8:00 AM, Paul Wouters wrote: > 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.
Except the attacker doesn't have to mess with a.root-server.net at all, as they can MitM the final application traffic just fine, and that final application either didn't trust the A record (so who cares if its tampered with), or gets 0wned by the MitM, so why bother at all? So for A records against a MitM, the signature for root-servers.net is irrelevant. For DNSSEC validation, this is irrelevant too: Either the final resolution MUST have a valid chain from the root of trust to the final value, OR there must be an NSEC record showing where the DNSSEC data ends. A bogus a.root-servers.net record won't affect this. >> 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 And in THAT case, the a.root-servers.net name doesn't matter either, because it is the signature chain for the TXT or CERT record that is validated. So for records validated on a client application, the signature for root-servers.net is irrelevant. So in either case, when your adversary is a MitM, the signature for root-servers.net is irrelevant: it is not validated and gains no BENEFIT from validation. Especially since the MitM can simply return bogus values from the REAL a.root-servers.net, and thats no different behaviorally. >> [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.... Except that for the client there actually IS a good answer: For the default, existing APIs (gethostbyname etc): conduct an iterative query from the root and use that value, for ANY signature or cryptographic failure, as the application using the API either is also trivially vulnerable to a MitM or doesn't really trust the record. For enhanced DNSSEC APIs: return the error to the client which, because its DNSSEC aware, should 'know what to do', or at least kick the problem to an application which may have a hope of doing something right. There is no such "good default answer" for the recursive resolver. >> 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. NSEC is about provable denial of DNSSEC information amongst anything else, no? So the path from your trust anchors must either be complete and validate OR have an NSEC record corresponding to the break. In either case, validating the name server's record for internal use doesn't affect the security of this chain. But it CAN add additional failure modes. DNSSEC MUST NOT significantly reduce the reliability of DNS, or the blowback will be extreme. And needlessly validating things that don't need to be validated CAN NOT increase security in the face of a man-in-the-middle (its not on the cryptographic trust path, and it is the cryptographic path that needs to be validated) but MUST reduce reliability. _______________________________________________ DNSOP mailing list [email protected] https://www.ietf.org/mailman/listinfo/dnsop
