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 Aug 12, 2008, at 6:56 PM, Dean Anderson wrote: This message seems to answer many of the questions over the last few days. .SE have 922 domains with DS records. The lack of .COM domains is probably because .COM is not signed. It is much easier to put a trust anchor in your resolver for .SE than to put 70 million trust anchors for all .COM domains. I for one is looking forward to what .ORG will do to the uplift on signed .ORG domains. And .SE does not even care about confidentiality, you should probably not store things in DNS that are supposed to be secret to begin with. -- patrik_wallstrom->foodfight->[EMAIL PROTECTED]>+46-733173956 smime.p7s Description: S/MIME cryptographic signature ___ 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 patc
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 Aug 12, 2008, at 11:40 AM, Dean Anderson wrote: 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. As has been pointed out, .COM is not signed. The fact that there are 99 zones signed in .COM is actually a bit surprising and points out one of the larger flaws with DNSSEC -- the assumption of a hierarchical top-down trust model in a world where the likeliest deployment model is bottom-up. For the signing of any of those 99 .COM zones to be useful, caching server operators have to manually configure/update the trust anchors for each of those zones. That obviously won't scale. And VeriSign hasn't exactly been chomping at the bit to sign .COM, quite the opposite as I understand it. Your argument would be stronger if you identified which TLD's and which RIR's. Last I checked: .SE, .BG, .PR, and .BR have been signed. RIPE-NCC signs the in-addr.arpa zones they are responsible for. I have been told there are several more top-level domains that have indicated they will be signing their zones before the end of the year. The IAB has asked IANA to sign .ARPA and its child zones and that process is underway, see https://ns.iana.org/dnssec/status.html (unfortunately, that effort has been a bit blocked for non-technical reasons). Others have indicated they are considering and/or attempting to do so, but are constrained for various reasons. Plans may have changed with the recent vulnerability announcements, but it would be inappropriate for me to pretend to speak for those TLD operators. Regards, -drc ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Kaminsky on djbdns bugs (fwd)
On Tue, 12 Aug 2008, Dean Anderson wrote: On Mon, 11 Aug 2008, Paul Wouters wrote: [Paul Wouters is a frequent NANOG poster.] a handful of postings in years is frequent? 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. "America is not the world" Your argument would be stronger if you identified which TLD's and which RIR's. http://www.xelerance.com/dnssec/ shows deployments per TPD, other people have created lists of domains within other unsecure TLD's. These are regularly posted to various lists, including dnssec-deployment, so loook there. On top of that, perhaps check out: http://ccnso.icann.org/surveys/dnssec-survey-report-2007.pdf For example it shows that of 61 TLD's, 7% deployed DNSSEC in production, 5% has a testbed running, and of the remaining TLD's that don't have an implementation going, 33% is going to deploy within the 1 year, and an additonal 38% is going to deploy in 3 years. It's really time to put the "dnssec is not deployed" myth to bed. 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. While historically intruiging, it has no relevance to DNSSEC. 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. You "answer" my question by inverting it, using a cows vs animals inversion. 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. Note for the record that I just explained YOUR circular logic. Thank you for confirming the flawed reasoning. I totally agree with you on that point. 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. Worse then current DNS deployments? That's pretty hard to do. Didn't you see or read Dan's presentation? 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. People *proposed* alternatives. They were just not accepted as valid alternatives that were better then DNSSEC. Dismissing the definite overt acts of misconduct as "conspiracy theory" is merely a tricky attempt to avoid the facts. Seeing how you responded to my emails, I am beginning to see their point. 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'. I responded to those. The current rushing is the "DNS is insecure! Adopt DNSSEC NOW!!!" No, the current solution was "Let's not force everyone into DNSSEC now, since that would be unsafe, so let's hack our way around a hack we did not like in the past, but which seems to only short-term stopgap. Let's co-ordinate a masive cross vendor source-port randomization patch". 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. Let me help your english parsing: " Show is the problems. [Brasil], [Sweden] and [RIPE's reverse tree] did not vanish". I expected someone like you to know there are no CCTLD reverse trees. Anyway, this di
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
