On Mon, 11 Aug 2008, Paul Wouters wrote: [Paul Wouters is a frequent NANOG poster.]
> DNSSEC has been deployed on large scale by some TLD's and RIR's already. > It is very much operational. Not very much--99 domains out of 70 million in .com. Your argument would be stronger if you identified which TLD's and which RIR's. > >>> Bernstein said that DNSSEC offers "a surprisingly low level of security" > >>> while causing severe problems for DNS reliability and performance. > >> > >> Let's not argue about the subjective "suprisingly". But what is this > >> "low level of security"? Is a fully trusted path 'low level'? If so, > >> what is 'high level'? > > > > I think http://cr.yp.to/talks/2004.04.28/slides.pdf might help. I think the recent message from Dr. Bernstein that I posted answers this far more clearly than I could. > How long do we hack around a system before before making a protocol > change? Sure, not every day, as EDNS0 proves, but surely using TXT > records and source port numbers for the next 25 years sounds like > overshooting it at the other end of the spectrum. This is a very good point. We had an opportunity to replace the protocol entirely in IPv6. That opportunity was squandered. Perhaps more questions should be asked about this squandered opportunity in the right forums, or maybe on a different subject line in this forum. > >> 1) What is more broken with DNSSEC then on DNS? > > > > The question really should be 'What is LESS broken with DNSSEC than with > > DNS?' > > This shows more an unwillingness to discuss then anything else. This is a completely irrational claim. > DNSSEC offers secure transport over plaintext channels of DNS data. > Perhaps not in a method you prefer, but that was not part of questions > 1). So at most here, you can answer "more cpu" and "more bandwidth" > and "more error prone by administrators". The first two are a direct > consquence of any solution that adds cryptography to a previous > solution not using cryptography. The error proneness is (and this is a > subjective opinion of mine) something we have to deal with, and DNSSEC > seems to be a reasonable approach to this, even if we're lacking a > little in proper tools to make it easier. > > > Equally broken is bad, too. 'More broken' is clearly a disaster. > > 'Not broken' is the goal. > > I'm not talking about English Lit. classes here. Stay on target please. I don't know what English Lit. has to do with anything. Clearly these degrees of brokeness of DNSSEC are relevant to a debate about DNSSEC problems. > >> 2) If DNSSEC is flawed, where is a better alternative? > > > > I think there are indeed better alternatives. Bernstein calls for > > development of alternatives. > > So there are better alternatives, but even Mr. Bernstein wants to develop > alternatives, suggesting to me that tehre are currently no alternatives. Nice circular logic there. > Which again leads to you requiring more proof of 1) before shooting down > DNSSEC. If there is nothing better, and DNSSEC does not make it worse (and > some complexity in return for fixing the recent Kaminsky class bugs seems > pretty acceptable to me), then it is you who needs to do the work of > developing these 'better alternatives' that you so desire. "Consensus > and Running Code"? The logic "if nothing better, therefore DNSSEC does not make it worse" is a fallacy. There can indeed be no alternative (and thus nothing better), while DNSSEC still makes things worse. > > But to find alternatives, IETF has to stop silencing the people who > > can figure out solutions, merely because those people oppose the > > BIND cartel. > > I'm skipping the conspiracy theory discussion bit. I see many clever people > who dare to stand up and show mistakes and propose alternatives. You just said there were no alternatives. Dismissing the definite overt acts of misconduct as "conspiracy theory" is merely a tricky attempt to avoid the facts. There is nothing hypothetical about the facts of the misconduct in silencing persons who opposed the BIND cartel. There is nothing hypothetical about the government documents that show the common control in the BIND cartel > > The BIND cartel gave us the flawed solutions; > > However, after I asked you to show these flaws, I was not answered. See > above. You were answered about flaws; I referred you to documents describing the flaws. The recent message from Dr. Bernstein more clearly answers the 'flaws issue'. > > deployment of another broken solution. Time and again we've seen this > > same pattern: Someone essentially yells "Emergency! Lets rush out this > > (non) solution! No time to think things through!". > > You are the first person I've ever heard say that DNSSEC was "rushed". The > other 99.99999% of people complained it took us more then 10 years. DNSSEC was a series of mistakes over a 15 year period. The current rushing is the "DNS is insecure! Adopt DNSSEC NOW!!!" drumbeat. "Take our patches without thinking or questioning our wisdom!!!" This drumbeat is no different from the 2003 "There is SPAM! Adopt SPF NOW!!!" In that case, SPF proponents proposed suspending the IETF rules to adopt the protocol quickly. (SPF turned out to make things worse via new DOS attacks, and didn't stop spam). Or take the 1999 cry "There is SPAM! REQUIRE Reverse DNS NOW!!!" This group is still working on the in-addr required document. There are more examples of people creating a sense of "urgency" to do things that turned out to be bad ideas, or at best, ineffective ideas. > > In almost every case, there is usually no emergency, and the > > 'solution' is frequently worse than the problem. > > Show is the problems. Brasil, Sweden and RIPE's reverse tree did not vanish > from the net when they implemented things. Resolvers of bug ISP's in Sweden > did not cause the Swedish endusers to lose connectivity to the internet. Oh---So if the reverse trees didn't vanish, everything must be alright... Sigh. --Dean -- Av8 Internet Prepared to pay a premium for better service? www.av8.net faster, more reliable, better service 617 344 9000 _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
