On 2012-10-28 5:55 AM, bert hubert wrote: > ... the trend that all purported cache poisonings observed have > been registry hacks. > > It appears that source port randomization works.
it doesn't, though. > Probably the only vulnerable servers are those behind NAT that derandomizes > the source port. But important servers are unlikely to suffer from network > address translation. DNS SPR is not universally deployed even among recursive name servers for large populations. and the de-randomization techniques described by shulman and herzberg (http://arxiv.org/pdf/1209.1482.pdf) work in what should be an alarming number of cases. but nobody is alarmed because attempted use of this vulnerability is at most "not widespread" and possibly also "rare". DNS SPR does not "work" in the sense that its non-universal deployment leaves significant attack surface uncovered. the reason we're not seeing wide spread poisoning isn't that DNS SPR is preventing it. the reason is, wide spread poisoning is not being attempted. On 2012-10-28 7:40 AM, bert hubert wrote: > ... people used the Kaminsky hack as a way to push DNSSEC. yes, we did. DNSSEC is a spend-money-to-save-money proposition, which is never compelling. those of us who knew that DNSSEC was needed and who had been working on it for over a decade by the time kaminsky came along were very happy to hear from kaminsky, and we rode the "fear curve" all the way to partial deployment, including seeing the root zone signed, seeing lots of TLD's signed, seeing DNSSEC as a requirement for all the new gTLD's, and seeing implementors who had previously eschewed DNSSEC decide to implement it after all. (for example, powerdnssec.) in that sense we were a bunch of fear-mongering opportunistic bastards. in our defense let me say that DNSSEC isn't an earn-money proposition for me or for most of the rest of the opportunistic bastards who climbed on the kaminsky band-wagon and trumpeted it as the reason why DNSSEC should be taken seriously. rather, we were concerned internet citizens who saw a long term problem that we knew others would not take seriously until the world's losses were significant. and, as DRC pointed out up-thread, DNS SPR is path protection and the path is already known to be corrupt (nxdomain redirection, dns filtering). the things DNSSEC prevents against are broader and more fundamental than kaminsky. so the geeks did some fear-based marketing to get a win. it's a win i'll take any way i can get it. we need DNSSEC. > ... It might have been easier all round to just start from scratch and not > pretend that this is 'an enhancement of DNS'. The length of the DNSSEC RFCs > exceeds the length of the standardizing RFCs of DNS. we naively believed that we could get DNSSEC into production before Y2K if we tried hard to work within the existing system. the idea of the root not being signed until 2010 was unthinkable. had we known that we had that much time we would have cut much deeper. sixteen years into the effort, DNSSEC is still not ready to become ubiquitous. less naively, i now know that had we cut deeper, as in use a new port number, call it "DNS V2", let initiators treat UDP/53 as a fallback path, then sixteen years would have been much too short. many people would have come out of the woodwork to help us. we would have unicode encoding of all names, XML encoding of all transactions, TLS security for all parts of the path, X.509 dependencies, no possibility of DANE, and most transactions would now use TCP. the result would never work outside anyone's lab, but would have been standardized anyway, several times over a twenty year span, by the end of which the world would have moved on to less open standards that could deliver usable functionality in fractional-year time frames. so it's probably for the best that we didn't know it would take sixteen years when we first started this. paul _______________________________________________ dns-operations mailing list [email protected] https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
