I've in general advocated client, rather than recursive resolver validation, and with the client doing "iterative fetch and accept" on all DNSSEC failures.
With the recent revelation that the NSA/GCHQ is doing packet-injection on the backbone, at scale, and even using this to target NATO allies, I've changed my tune. Even forget about NSA/GCHQ directly, they've now implicitly said that "hey, its OK" for everyone else to do it, too. Backbone DNS injection allows converting a man-on-the-side attacker (who, eg, even with a certificate, can't intercept TLS using perfect forward secrecy, and who when attacking HTTP can only see requests before deciding what to do) into a full man-in-the-middle, as long as the attacker knows the target's recursive resolver. Thus I've changed my tune: 1: Recursive resolvers MUST validate DNSSEC as well as clients. Not because I trust the recursive resolver, but there is now an adversary set where recursive resolver validation does help, and its an easier point to do. 2: Validation failures due to bad signatures/etc MUST result in a failure unless specifically whitelisted. 3: Future protocols MUST support "Connect by multiple name" semantics: Given MULTIPLE names, only connect if all K names have the same IP after resolution. (This enables multiple-validation-path DNSSEC, which is a pretty uni). -- Nicholas Weaver it is a tale, told by an idiot, [email protected] full of sound and fury, 510-666-2903 .signifying nothing PGP: http://www1.icsi.berkeley.edu/~nweaver/data/nweaver_pub.asc
signature.asc
Description: Message signed with OpenPGP using GPGMail
_______________________________________________ DNSOP mailing list [email protected] https://www.ietf.org/mailman/listinfo/dnsop
