I've been a big advocate on the DNSSEC related lists that "Eh, the recursive resolver is the enemy, so validate on the client and don't bother validating on the recursive resolver".
With the recent revelation that the NSA/GCHQ is doing packet-injection/man-on-the-side attacks 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 directly 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 unique feature of DNSSEC. I may not trust Verisign/NSA. I certainly do not trust the Russians. But I can probably trust that .com and .ru won't be subverted by the same parties. -- 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
_______________________________________________ perpass mailing list [email protected] https://www.ietf.org/mailman/listinfo/perpass
