On Oct 21, 2013, at 5:11 AM, Dan York <[email protected]> wrote: > Good document. In a quick read I naturally have to react to slide 23 > (Trusting DNS) and also slide 11 (Certificate Authority). On slide 23, > you say "Sorry, can't trust this yet.", but what happens as we get more > DNSSEC deployed? We're already seeing increased validation within caching > resolvers and some measurements are showing around 8% of all DNS queries > coming from resolvers that perform validation. We're seeing steady growth > in the number of DNSSEC-signed domains. I know there are those who are > skeptical about DNSSEC deployment, but I'm definitely seeing real > growth... and see a number of trends pointing to that only continuing.
DNSSEC has two huge issues and one huge potential (untapped) advantage. Issue #1: Validation at the wrong place. Recursive resolver validation is of only small (but non-zero) utility: It allows countering packet-injection (NSA and their foreign competitors), which can otherwise be used to promote a man-on-the-side to a full man-in-the-middle. But the recursive resolver itself is proven untrustworthy, so its not the point which should conduct validation. And if clients are to validate in a mandatory way, they need to be able to get DNSSEC over an alternate means, as many clients can't get DNSSEC over the wire on UDP 53, many others can't get DNSSEC from the recursive resolver, and the combination (can't get either from the wire OR recursive resolver) is high enough that its in the "break 1%" category, which is generally regarded as unacceptable. Issue #2: The big threat against DNS, and the big reason you can't trust it, is that the major high-profile attacks have been attacks on the registrar. DNSSEC does no good, because if you can social engineer the registrar, you can also get new DS records accepted. Untapped advantage: Multiple paths of trust. If, say, TLS was modified to have multiple hostnames, eg https://www.example.com/www.example.ru/ where the resulting certificate is fetched through DNSSEC, and BOTH domains must agree, in order for the connection to proceed. This provides a very unique property: it requires that all paths-of-trust be compromised by the same cooperating entity. That is . -> .com -> example.com . -> .ru -> example.ru both must be compromised by the same entity. "I don't trust .com, I don't trust .ru, but I trust they won't collude against me" is a very interesting property that is unique to protocols built on top of DNSSEC-as-a-CA. -- 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
