Re: [DNSOP] Kaminsky on djbdns bugs (fwd)
On Aug 13, 2008, at 10:28 PM, Masataka Ohta wrote: I presented the real-world statistical data to support my claim that DNSSEC requires to much work. That is, it is hardly deployed because it requires to much work. I must have missed that message. Does your personal experience have any statistical significance? No. Rather, what it says is that .COM is not signed. To be statistical, which you requested, how many TLDs among many are signed? Sounds like four. And with the root zone not signed, the pressure on the TLDs to sign their zones is essentially zero. And at least according to the latest article on DNSSEC in Wired, the reason why it is not signed is that the agency currently responsible for operating it wants to study the process further. No mention was made of the difficulty of signing. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Kaminsky on djbdns bugs (fwd)
I presented the real-world statistical data to support my claim that DNSSEC requires to much work. That is, it is hardly deployed because it requires to much work. The reason it's hardly deployed is that people don't see the point. COM and the root zone aren't signed, so there's no perceived benefit. Most people would agree that *any* amount of work is too much when there's no perceived benefit. It would be more interesting to see what percentage of .SE and .BR domains are signed: There *is* some perceived benefit there, and an infrastructure in place. I would expect the cost/benefit analysis to shift in favor of DNSSEC under those circumstances. I actually agree with you that DNSSEC using BIND is more fiddly, arcane and time-consuming than it ought to be. (And I intend to improve it.) But that flaw is in the tools, not the protocol. There are lots of other things about network configuration that used to be fiddly and arcane and have since become simple; you seem to be arguing that DNSSEC won't follow suit, but I see no technical reason why it shouldn't. -- Evan Hunt -- [EMAIL PROTECTED] Internet Systems Consortium, Inc. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Kaminsky on djbdns bugs (fwd)
On Aug 13, 2008, at 4:04 AM, Masataka Ohta wrote: Maybe, Ted could provide some virtual-world data realistic enough to deny the real-world statistical data such as: djb Last week's surveys by the DNSSEC developers (SecSpider) have found a djb grand total of 99 signed dot-com names out of the 70 million dot-com djb names on the Internet Ohta-san, you made the claim that managing DNSSEC is so much more work than maintaining regular DNSSEC that the cost of doing so outweighed the benefit of doing so - the added security. You provided no statistics to back up that claim, and that claim is contrary to my own personal experience with setting up DNSSEC. The statistic you present above is probably true, and certainly matches my personal experience. However, it says nothing about how much work is involved in setting up and maintaining DNS zones. Rather, what it says is that .COM is not signed. There's no security benefit to signing your zone if the trust anchor on which your zone depends is not signed. So this statistic is not part of the cost/ benefit analysis we were talking about - it's a non-sequitur. It's certainly true that in order for .COM zones to get any meaningful security out of DNSSEC, either .COM has to be signed, or we have to use some other trust anchor mechanism, like DLV or DLVPTR, so if you wanted to use this statistic to justify deploying some alternative trust anchor system, that would make sense. BTW, one exercise that I'd like to suggest for participants in this discussion is that, despite the fact that .COM is not signed, you sign your .COM zones if you haven't already. I'm in the process of doing that myself. Given that only 90 are signed so far, I suspect that a lot of DNS geeks just haven't bothered yet because .COM isn't signed. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Kaminsky on djbdns bugs (fwd)
On Aug 13, 2008, at 10:21 AM, Ralf Weber wrote: Hmm, assuming that we both did use the same name server software my experiences are different. Compared to regular DNS setting up and more importantly maintaining DNSSEC is much more work than normal DNS stuff (zone resigning, key rollover) . You're probably doing too much work. Why are you doing key rollover? Why so often? Why not just use a longer key? Are you trying for more security than you actually need? Are you that careful with your SSL certs? And why aren't you signing your zone with a cron job? For me, the hardest problem about setting up a secure zone was simply finding concise documentation on how to do it. I just set up a secure zone in .se, and the total work time from deciding to do it to having it done was about an hour, including: - tracking down and reading Olaf's rather verbose but quite helpful document on setting it up (http://www.nlnetlabs.nl/dnssec_howto/) - debugging two problems with my zone that weren't DNSSEC-related, but that the DNSSEC signer wouldn't allow - finding a registrar who was happy to communicate with me in English, since I don't speak Swedish (thanks, Patrik!) - registering a new domain, not just setting up DNSSEC. Maybe I did it wrong, but it seemed pretty easy to me. I think the problem is just that people don't know how to do it, and overthink the problem. Oh, I just now signed two more of my top-level zones. 13 minutes to do two of them, and this was doing it manually, with no shell scripts to automate it. Of course, they're in .COM and .ORG, so there's no trust anchor yet, but hopefully there will be some day. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Kaminsky on djbdns bugs (fwd)
On Wed, 13 Aug 2008 19:21:44 +0200, Ralf Weber [EMAIL PROTECTED] said: RW Hmm, assuming that we both did use the same name server software my RW experiences are different. Compared to regular DNS setting up and more RW importantly maintaining DNSSEC is much more work than normal DNS stuff RW (zone resigning, key rollover) . I am not saying that the cost RW generally outweighs the benefit, but with the current tools it is RW hard to justify DNSSEC usage, at least for the majority of ISPs out RW there. But I do hope that the tools get better and thus the cost of RW deploying DNSSEC decreases and we will all happily use it and can RW justify it's usage. I suspect there are many different tools out there and some are easier than others. Here's a screen dump of stuff that works easily for me: # yum install dnssec-tools # head example.com $TTL 3600 ; File written on Thu Dec 23 14:13:02 2004 ; dnssec_signzone version 9.3.0 example.com.600 IN SOA test.example.com. admin.example.com. ( 2004121002 ; serial 7200 ; refresh (2 hours) 3600 ; retry (1 hour) 604800 ; expire (1 week) 600; minimum (10 minutes) ) # zonesigner -genkeys example.com if zonesigner appears hung, strike keys until the program completes (see the Entropy section in the man page for details) zone signed successfully example.com: KSK (cur) 36712 -b 2048 08/13/08 (example.com-signset-3) ZSK (cur) 01857 -b 1024 08/13/08 (example.com-signset-1) ZSK (pub) 53523 -b 1024 08/13/08 (example.com-signset-2) zone will expire in 4 weeks, 2 days, 0 seconds DO NOT delete the keys until this time has passed. # cp example.com.signed /etc/named/ # rndc reload Oh wait... i need another record and need to resign... # echo test.example.com. 1D IN A 127.0.0.1 example.com # zonesigner example.com if zonesigner appears hung, strike keys until the program completes (see the Entropy section in the man page for details) zone signed successfully example.com: KSK (cur) 36712 -b 2048 08/13/08 (example.com-signset-3) ZSK (cur) 01857 -b 1024 08/13/08 (example.com-signset-1) ZSK (pub) 53523 -b 1024 08/13/08 (example.com-signset-2) zone will expire in 4 weeks, 2 days, 0 seconds DO NOT delete the keys until this time has passed. # cp example.com.signed /etc/named/ # rndc reload Not too hard really. The only thing you need to add to your current step for distributing a zone is one new line (the zonesigner line). The hardest thing you need to do, IMHO, is make sure you redistribute a new zone before the current set of stuff expires. IE, publish it once a month (using the default setup shown above). And if that's the hardest thing for me to do then I don't consider that hard. -- In the bathtub of history the truth is harder to hold than the soap, and much more difficult to find. -- Terry Pratchett ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Kaminsky on djbdns bugs (fwd)
Ted Lemon wrote: No, Ohta-san. It _is_ more secure. Security is relative, not absolute. Are you really talking about relative security? If you are talking about security relative to the amount of operational effort (that is, money!!!), PODS is definitly more secure than DNSSEC. Masataka Ohta ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Kaminsky on djbdns bugs (fwd)
[no hat] On Tue, Aug 12, 2008 at 12:00:09PM +0900, Masataka Ohta wrote: Social implementations of DNSSEC may be (or, considering its complexity, will always be) vulnerable to tampering from any person. This seems like a strong claim. Are you really just claiming that, because humans are involved and because it depends on proving trust relationships; and because we know that humans make a lot of errors; therefore, DNSSEC is only as strong as the operational practices of the weakest point in the chain of trust? A -- Andrew Sullivan [EMAIL PROTECTED] +1 503 667 4564 x104 http://www.commandprompt.com/ ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Kaminsky on djbdns bugs (fwd)
On Aug 11, 2008, at 11:00 PM, Masataka Ohta wrote: If you are talking about security relative to the amount of operational effort (that is, money!!!), PODS is definitly more secure than DNSSEC. I think if you were to try to explain this by presenting real-world statistical data to support your argument, your argument might become convincing. When you say it like this, though, it sounds like baseless speculation. And that certainly matches my personal experience in working with DNSSEC - the difference in effort seems to me to be orders of magnitude less than what you are suggesting. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Kaminsky on djbdns bugs (fwd)
This message seems to answer many of the questions over the last few days. -- Av8 Internet Prepared to pay a premium for better service? www.av8.net faster, more reliable, better service 617 344 9000 -- Forwarded message -- Date: 10 Aug 2008 00:28:22 - From: D. J. Bernstein [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Re: Kaminsky on djbdns bugs Last week's surveys by the DNSSEC developers (SecSpider) have found a grand total of 99 signed dot-com names out of the 70 million dot-com names on the Internet. Am I the only person amazed by this? We've had fifteen years of forgeries, fifteen years of concentrated work on DNSSEC, and we can't even get simple cryptographic signatures deployed. What an embarrassment for cryptography! Jos Backus writes: http://cr.yp.to/djbdns/forgery.html states: My top priority for djbdns is to support nym-based security. Hmmm. This reminds me that some web-page updates are overdue; it's time for me to announce the results of the attacks that the entire Internet will be panicking about in 2015. :-) When I wrote that web page several years ago, I focused on deployment difficulties (which are obviously a huge issue) and delegating security to poorly managed central Internet servers (which is a big issue for high-security sites). But there are other reasons, maybe more important reasons long term, to be dissatisfied with DNSSEC, motivating the development of DNSSEC2 and DNSSEC3: * RFC 4033, Section 4: DNSSEC provides no protection against denial of service attacks. In fact, DNSSEC makes denial of service even easier than it was before. The basic problem is that DNSSEC signs _records_ but provides no protection for _packets_. After several packets a DNSSEC cache can see that it doesn't have the expected signatures and that there must have been forgeries, but the cache simply fails at that point; it doesn't have any way to find the right data. With DNSSEC2, every response packet has an immediately and efficiently verifiable high-security cryptographic signature. Forged packets are simply discarded. * RFC 4033, Section 4: DNSSEC is not designed to provide confidentiality. DNSSEC doesn't even try to encrypt packets. In fact, DNSSEC makes private DNS data _much_ easier for attackers to see than before, because it exposes a huge amount of information through NSEC, and creates interoperability failures if NSEC is disabled. The latest NSEC3 adds even more complications but does essentially nothing to repair the privacy leaks; NSEC3 might be successful at its marketing goal of stopping European privacy regulators but it will almost never be successful at the security goal of stopping attackers. With DNSSEC3, every request and response packet has high-security encryption and authentication. Both DNSSEC2 and DNSSEC3 completely avoid the NSEC privacy leaks. * Although the DNSSEC protocol allows some conservative cryptographic options that won't be broken in the near future, what DNSSEC users are actually being told to deploy---to partially compensate for serious speed problems in DNSSEC---is something that big companies and botnet operators can _already_ break, namely 1024-bit RSA. We're still years away from a _public_ announcement of a successful 1024-bit RSA factorization, but I think that telling people to use 1024-bit RSA today is completely irresponsible. These issues are separate from the question of how keys are distributed. DNSSEC, DNSSEC2, and DNSSEC3 distribute public keys through parent servers (as simple NS names in the case of DNSSEC2 and DNSSEC3), so of course the parent servers can substitute any data they want. DNSSEC2 and DNSSEC3 have the extra option of embedding public keys into URLs so that parent servers can't do more damage than turning off service. ---D. J. Bernstein, Professor, Mathematics, Statistics, and Computer Science, University of Illinois at Chicago ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Kaminsky on djbdns bugs (fwd)
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.9% 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
Re: [DNSOP] Kaminsky on djbdns bugs (fwd)
On Tue, 12 Aug 2008, Mark Andrews wrote: TCP, port randomisation, 0x20, EDNS PING etc. all leave gapping holes in the security model which are being exploited today. I don't know of any TCP exploits today. Though TCP is not secure against anyone in the path of the packets, its pretty invulnerable to spoofing attacks conducted if the attacker can't see the packets. TCP is vulnerable to other kinds of DOS attacks such as synflood or connection reset. Synfloods are handled by existing mitigation techniques. The shorter the transaction, the harder it is to effect connection reset, but connection caching improves efficiency. TCP is pretty robust in most situations. TCP: Get truth or nothing, unless liar in the path UDP: Get something, even a lie from anywhere DNSSEC: Everybody might get nothing, but the TLD and root operators are entrenched. No alternate roots. Pick your poison (pun intended ;-) --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
Re: [DNSOP] Kaminsky on djbdns bugs (fwd)
On 12 Aug 2008, at 14:50, Dean Anderson wrote: On Tue, 12 Aug 2008, Mark Andrews wrote: TCP, port randomisation, 0x20, EDNS PING etc. all leave gapping holes in the security model which are being exploited today. I don't know of any TCP exploits today. Imagine being able to intercept arbitrary flows of packets between targeted remote ASes in such a way that the remote ASes could not easily tell that anything was going on. Imagine that traceroutes from the perspective of the remote ASes continue to look normal, or at least similar to normal. http://eng.5ninesdata.com/~tkapela/iphd-2.ppt How much protection does the use of TCP buy you in that scenario? Joe ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Kaminsky on djbdns bugs (fwd)
the fact that masataka's proposal seemed qualitatively better to me eleven years ago is moot. the reason dnssec isn't deployed yet has nothing to do with any such qualitative differences. we are where we are, and what we've got to do now is deploy what we've got now. the dnssec spec at present may be ugly but it is practicable, and there's a large body of expertise and running code and commercial products and interoperability testing behind it. while i didn't enjoy watching masataka's proposal railroaded into the ditch and while it would have taken less time to get masataka's dnssec proposal deployable than it has taken to get to what we've got now, the silver lining for me was that i learned how to railroad my own proposals through IETF using the techniques i learned. RFC 2136, RFC 2671, and RFC 2845 all exist only because of the dirty tricks i learned by watching masataka's mistreatment. (had i known at the outset how IETF worked, i would have worked to prevent that mistreatment, but i was a n00b.) -- Paul Vixie -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Kaminsky on djbdns bugs (fwd)
On Sat, 9 Aug 2008, Paul Wouters wrote: DNSSEC, a cryptographic version of DNS, has been in development since 1993 but is still not operational. It seems that Mr. Bernstein also suffers from the America is the not the world syndrome. ??? 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. We need to stop wasting time on breakable patches, Bernstein said. He called for development of DNSSEC alternatives that quickly and securely reject every forged DNS packet. This statement even goes so far as to suggest DNSSEC is a breakable patch In general, for all those people who claim DNSSEC is not the solution, I have a few questions 1) What is more broken with DNSSEC then on DNS? The question really should be 'What is LESS broken with DNSSEC than with DNS?' Equally broken is bad, too. 'More broken' is clearly a disaster. 'Not broken' is the goal. 2) If DNSSEC is flawed, where is a better alternative? I think there are indeed better alternatives. Bernstein calls for development of alternatives. But to find alternatives, IETF has to stop silencing the people who can figure out solutions, merely because those people oppose the BIND cartel. The BIND cartel gave us the flawed solutions; It did this by silencing the opposition to create a false consensus on their ideas. The cartel continues to exercise control of (at least) IETF DNSEXT and continues to silence its critics, even though its credibility at solving these problems should have been exhausted a long time ago. Silencing the cartel's critics was improper. Without answering those questions, you can't really reject DNSSEC over the alternative of keeping to run DNS as we have so far. Sure you can reject DNSSEC. One broken solution doesn't justify 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!. In almost every case, there is usually no emergency, and the 'solution' is frequently worse than the problem. --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
Re: [DNSOP] Kaminsky on djbdns bugs (fwd)
Dean Anderson wrote: 1) What is more broken with DNSSEC then on DNS? DNSSEC is, socially, more dangerous than PODS, because DNSSEC gives users false sense of security. The question really should be 'What is LESS broken with DNSSEC than with DNS?' Equally broken is bad, too. 'More broken' is clearly a disaster. 'Not broken' is the goal. I was enlightened on two things through designing and improving simple secure DNS, which is a PKI-based cryptographically secure DNS consistent with PODS. They are: 1) precise authority model of referral and glue A, which is why I know how to fix cache contamination through glue A 2) Meaninglessness of DNSSEC, or PKI in general, with no better security than PODS Just like the Internet is a network of ISPs and end users, a PKI is a network of CAs and end users. If you can blindly believe in that CAs and end users are secure, you can blindly believe in that ISPs and end users are secure, both of which are, of course, wrong. However, with PKI the former is silently assumed and PKI is claimed to be cryptographically secure, which is the fallacy of PKI. For example, even if you make your signature generation mechanism not accessible online through the Internet, the mechanism must be, to keep the PKI work, accessible through the network of CAs and end users, which means the mechanism is effectively online, where effectively means attacking is equally easy. That is, WG discussion on securing NXDOMAIN has been totally meaningless. For another example, just as a packet with 16 bit ID and 32 bit source address should not be blindly believed, a person with an ID badge with 16 digit ID and issuer's name of your parent CA should not be blindly believed, though both of them are blindly believed so often. To break DNSSEC, a phishing site pretending as your parent CA and requesting you enter your private key is often enough. 2) If DNSSEC is flawed, where is a better alternative? I think there are indeed better alternatives. As I already posted, try to improve implementations to use TCP with random sequence number and random port, which is not more difficult than to improve caching behavior of implementations. Masataka Ohta ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Kaminsky on djbdns bugs (fwd)
Dean Anderson wrote: 1) What is more broken with DNSSEC then on DNS? DNSSEC is, socially, more dangerous than PODS, because DNSSEC gives users false sense of security. The question really should be 'What is LESS broken with DNSSEC than with DNS?' Equally broken is bad, too. 'More broken' is clearly a disaster. 'Not broken' is the goal. I was enlightened on two things through designing and improving simple secure DNS, which is a PKI-based cryptographically secure DNS consistent with PODS. They are: 1) precise authority model of referral and glue A, which is why I know how to fix cache contamination through glue A 2) Meaninglessness of DNSSEC, or PKI in general, with no better security than PODS Just like the Internet is a network of ISPs and end users, a PKI is a network of CAs and end users. If you can blindly believe in that CAs and end users are secure, you can blindly believe in that ISPs and end users are secure, both of which are, of course, wrong. However, with PKI the former is silently assumed and PKI is claimed to be cryptographically secure, which is the fallacy of PKI. For example, even if you make your signature generation mechanism not accessible online through the Internet, the mechanism must be, to keep the PKI work, accessible through the network of CAs and end users, which means the mechanism is effectively online, where effectively means attacking is equally easy. You already have to trust your parents to publish your delegating NS RRset. If they don't then you are in trouble. DNSSEC does not change that pre-existing trust relationship which is required for DNS to work. Unless you control all aspects of the communication you end up having to trust someone. The question is who do you trust and is that appropriate for the thing that is being secured. The DNSSEC trust model is in parallel to the trust model of the thing it is securing (DNS). That is, WG discussion on securing NXDOMAIN has been totally meaningless. That really depends on which persons you are attempting to prevent tampering from. For another example, just as a packet with 16 bit ID and 32 bit source address should not be blindly believed, a person with an ID badge with 16 digit ID and issuer's name of your parent CA should not be blindly believed, though both of them are blindly believed so often. To break DNSSEC, a phishing site pretending as your parent CA and requesting you enter your private key is often enough. Which like most things to do with security is a matter of education. 2) If DNSSEC is flawed, where is a better alternative? I think there are indeed better alternatives. As I already posted, try to improve implementations to use TCP with random sequence number and random port, which is not more difficult than to improve caching behavior of implementations. TCP only addresses one of the issues. Masataka Ohta ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: [EMAIL PROTECTED] ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Kaminsky on djbdns bugs (fwd)
To break DNSSEC, a phishing site pretending as your parent CA and requesting you enter your private key is often enough. Which like most things to do with security is a matter of education. To which I should have added. With DNSSEC you *never* need to disclose you private key. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: [EMAIL PROTECTED] ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Kaminsky on djbdns bugs (fwd)
Mark Andrews wrote: DNSSEC is, socially, more dangerous than PODS, because DNSSEC gives users false sense of security. You already have to trust your parents to publish your delegating NS RRset. So, technically, DNSSEC is no worse but no better than PODS. That is, WG discussion on securing NXDOMAIN has been totally meaningless. That really depends on which persons you are attempting to prevent tampering from. Social implementations of DNSSEC may be (or, considering its complexity, will always be) vulnerable to tampering from any person. Which like most things to do with security is a matter of education. Quick upgrading of programs with open security holes is another, but a lot easier, matter of education. So, if we are discussing security in the real world, let's never assume that people are automagically educated to treat all the complex aspects of DNSSEC operations properly. As I already posted, try to improve implementations to use TCP with random sequence number and random port, which is not more difficult than to improve caching behavior of implementations. TCP only addresses one of the issues. Let's accept the reality that DNS operation is human and can not be very secure. Masataka Ohta ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Kaminsky on djbdns bugs (fwd)
On Aug 11, 2008, at 6:34 PM, Masataka Ohta wrote: DNSSEC is, socially, more dangerous than PODS, because DNSSEC gives users false sense of security. The average user has a false sense of security completely independent of what the underlying protocol is. So what matters is not what sense of security the user has, but what actual security the user has. We can't control what the user thinks or does. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Kaminsky on djbdns bugs (fwd)
Ted Lemon wrote: DNSSEC is, socially, more dangerous than PODS, because DNSSEC gives users false sense of security. So what matters is not what sense of security the user has, but what actual security the user has. The false sense of security makes people unconditionary accept DNS result. Worse, they think not only attackers but also victims are responsible for damages. We can't control what the user thinks or does. How can you explain the evidence that many people here think DNSSEC more secure than PODS merely because it is called DNSSEC? Are they less-than-average users? Masataka Ohta ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Kaminsky on djbdns bugs (fwd)
On Aug 11, 2008, at 8:36 PM, Masataka Ohta wrote: How can you explain the evidence that many people here think DNSSEC more secure than PODS merely because it is called DNSSEC? Are they less-than-average users? No, Ohta-san. It _is_ more secure. Security is relative, not absolute. You could reasonably question whether the delta in security is worth the price we'd pay, but calling people names isn't part of that process. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Kaminsky on djbdns bugs (fwd)
On Sat, Aug 09, 2008 at 04:33:55PM -0400, Paul Wouters wrote: In general, for all those people who claim DNSSEC is not the solution, I have a few questions 1) What is more broken with DNSSEC then on DNS? 2) If DNSSEC is flawed, where is a better alternative? An alternative was proposed by Masataka Ohta around 1995. It did not progress, but maybe it is time to trawl the archives and revisit it? http://www.ops.ietf.org/lists/namedroppers/namedroppers.2006/msg01512.html http://www.ops.ietf.org/lists/namedroppers/namedroppers.2006/msg01516.html http://www.ops.ietf.org/lists/namedroppers/namedroppers.2006/msg01520.html On the other hand, the comment from Masataka Ohta was: the real problem of DNSSEC is that it is merely weakly secure so suggesting that a fundamental rethink is necessary. -- Andras Salamon [EMAIL PROTECTED] ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Kaminsky on djbdns bugs (fwd)
Tony Finch wrote: On Sun, 10 Aug 2008, Ted Lemon wrote: Paul's comment (the first of the three articles you quoted) implies that secure NXDOMAIN is not a feature of Ohta-san's proposal. That seems like a bit of a problem, because fake domains are definitely a useful phishing tool. As far as I can tell from the draft linked below, it does support secure NXDOMAIN and could be made to do so without allowing zone enumeration. http://www.watersprings.org/pub/id/draft-ohta-simple-dns-02.txt ZL is effectively NSEC, so suffers from the same problem. A ZL3 would be required. With all its attendant problems. Cheers, Ben. -- http://www.apache-ssl.org/ben.html http://www.links.org/ There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit. - Robert Woodruff ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Kaminsky on djbdns bugs (fwd)
On Sun, 10 Aug 2008, Ben Laurie wrote: Tony Finch wrote: On Sun, 10 Aug 2008, Ted Lemon wrote: Paul's comment (the first of the three articles you quoted) implies that secure NXDOMAIN is not a feature of Ohta-san's proposal. That seems like a bit of a problem, because fake domains are definitely a useful phishing tool. As far as I can tell from the draft linked below, it does support secure NXDOMAIN and could be made to do so without allowing zone enumeration. http://www.watersprings.org/pub/id/draft-ohta-simple-dns-02.txt ZL is effectively NSEC, so suffers from the same problem. A ZL3 would be required. With all its attendant problems. The first and last domains that bracket the list don't have to exist in the zone: you can just return an empty ZL record that brackets the QNAME as a proof of nonexistence. However you'd have to generate and sign the record on the fly so it's not really practical, and you're right that something better is required. Tony. -- f.anthony.n.finch [EMAIL PROTECTED] http://dotat.at/ SOLE LUNDY FASTNET IRISH SEA: SOUTHWESTERLY BACKING SOUTHERLY 5 OR 6, OCCASIONALLY 7 IN FASTNET. ROUGH. RAIN OR SHOWERS. MODERATE OR GOOD, OCCASIONALLY POOR. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Kaminsky on djbdns bugs (fwd)
DNSSEC, a cryptographic version of DNS, has been in development since 1993 but is still not operational. It seems that Mr. Bernstein also suffers from the America is the not the world syndrome. 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'? We need to stop wasting time on breakable patches, Bernstein said. He called for development of DNSSEC alternatives that quickly and securely reject every forged DNS packet. This statement even goes so far as to suggest DNSSEC is a breakable patch In general, for all those people who claim DNSSEC is not the solution, I have a few questions 1) What is more broken with DNSSEC then on DNS? 2) If DNSSEC is flawed, where is a better alternative? Without answering those questions, you can't really reject DNSSEC over the alternative of keeping to run DNS as we have so far. Paul ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Kaminsky on djbdns bugs (fwd)
FYI: It would be nice if someone could repost this the namedroppers. This might inform some of the discussion going on there. Both DJB and I have problems posting to namedroppers for basically the same reasons---opposing the BIND cartel. However, getting this information distributed seems to be important enough to be widely distributed. Make sure you read the UIC announcement included at the end. I'm greatly enjoying the Olympics; have fun! --Dean -- Forwarded message -- Date: 8 Aug 2008 03:42:28 - From: D. J. Bernstein [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Re: Kaminsky on djbdns bugs Kyle Wheeler writes: That makes it easier for an attacker to guess the right number, but only somewhat (your chances per-guess go from one in four billion to, say, thirty in four billion). This criticism of djbdns seems somewhat... well, specious. http://cr.yp.to/djbdns/forgery.html has, for several years, stated the results of exactly this attack: The dnscache program uses a cryptographic generator for the ID and query port to make them extremely difficult to predict. However, * an attacker who makes a few billion random guesses is likely to succeed at least once; * tens of millions of guesses are adequate with a colliding attack; etc. The same page also states bilateral and unilateral workarounds that would raise the number of guesses to practically impossible; but then focuses on the real problem, namely that attackers with access to the network would still be able to forge DNS responses. I suppose I should be happy to see public awareness almost catching up to the nastiest DNS attacks I considered in 1999. However, people are deluding themselves if they think they're protected by the current series of patches. UIC is issuing a press release today on this topic; see below. ---D. J. Bernstein, Professor, Mathematics, Statistics, and Computer Science, University of Illinois at Chicago DNS still vulnerable, Bernstein says CHICAGO, Thursday 7 August 2008 - Do you bank over the Internet? If so, beware: recent Internet patches don't stop determined attackers. Network administrators have been rushing to deploy DNS source-port randomization patches in response to an attack announced by security researcher Dan Kaminsky last month. But the inventor of source-port randomization said today that new security solutions are needed to protect the Internet infrastructure. Anyone who knows what he's doing can easily steal your email and insert fake web pages into your browser, even after you've patched, said cryptographer Daniel J. Bernstein, a professor in the Center for Research and Instruction in Technologies for Electronic Security (RITES) at the University of Illinois at Chicago. Bernstein's DJBDNS software introduced source-port randomization in 1999 and is now estimated to have tens of millions of users. Bernstein released the DJBDNS copyright at the end of last year. Kaminsky said at the Black Hat conference yesterday that 120,000,000 Internet users were now protected by patches using Bernstein's randomization idea. But Bernstein criticized this idea, saying that it was at best a speed bump for blind attackers and an extremely poor substitute for proper cryptographic protection. DNSSEC, a cryptographic version of DNS, has been in development since 1993 but is still not operational. Bernstein said that DNSSEC offers a surprisingly low level of security while causing severe problems for DNS reliability and performance. We need to stop wasting time on breakable patches, Bernstein said. He called for development of DNSSEC alternatives that quickly and securely reject every forged DNS packet. Press contact: Daniel J. Bernstein [EMAIL PROTECTED] -30- ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
