Re: update on the djbdns bugs?

The mathematics of the 'Kaminsky bug' are well-known and have been known
for a very long time, and have been discussed as recently as 2006 in the
development of the Unbound DNS software. Kaminsky didn't discover this
problem, and I cringe at calling it the "Kaminsky Bug", but I'll try to
let that go. However, if there IS a new (non-QUID prediction) problem
with DJB DNS,

  then please describe your view of the problem, and your proposed fix;

That is what responsibility requires. One doesn't need to identify every
software that suffers the same problem. Others will be happy to
determine if other software suffers the same problem, particularly the
support groups for the other software.  One doesn't need to fully
understand mathematics. These reasons are not cause not to release the
problem discription and your proposed fix.  Others will figure out the
mathematics.  And _if_ the problem and proposed fix isn't really a
problem or is an already-known problem, for mathematical reasons, others
will figure that out, too.

I think that trying to work alone and outside of the DJBDNS community
and its support groups to try to conduct a mathematical analysis of the
problem you see with DNSCACHE and analyze the correctness of the fix is
at least undesirable and should be a last resort; something done only if
the community refuses to help or cooperate.

I think you should state what you know of the problem so far, and what
you think the fix is, and let us work on the solution, the risk, and the
mathematics.  

<soapbox> 

I, for one, have grown tired of the notion that a dubious claim,
ultimately discredited on its originality, should justify the urgent
adoption of untried, and possibly unreliable patches to critical DNS
software. Especially, coming as this claim did from a self-discredited
source: Kaminsky himself disclosed that his group has been wrong for a
long time about DNS. If fact, Kaminsky's group was ignorant and indeed
didn't understand a great deal about DNS: they missed the QID prediction
spoofing additional records, even though this was long known.  Yet, we
are to trust them with untried patches?  This just reminds me of the
Financial mess.

I take it as an general axiom that the people who get us into a mess
shouldn't be rewarded with greater trust and responsibility, but rather
should be demoted and given less trust and responsiblity. I call that
accountability.

Much talk has been given over to whether punishing those responsible for
the financial mess is just hurting ourselves; akin to cutting off the
nose to spite the face. Some say rules were broken and people misled.
Others say these were just honest mistakes and people were simply wrong.  
I think these debates are hair-splitting in some respects. It doesn't
matter whether the mess is because the people weren't honest or whether
it is because honest mistakes were made by people who merely weren't
fully competent.  What really matters is those people who messed up
can't continue to be trusted in the future at the same level they were
in the past.

When people don't follow the rules or are ignorant in their
responsibilities, the problem can't be fixed by more rules. One must
take the trust and responsibility away from those people who caused the
mess. It doesn't matter why the rules were broken or why the people were
wrong. It only matters that they are held accountable for the serious
mess they created. I think this is true of the Kaminsky Debacle and the
Financial mess. I hope we don't do either of these things again.  
Perhaps both areas are in need of more government oversight, if only to
ensure there is accountability.

</soapbox>


		--Dean



On Sun, 28 Sep 2008, Kevin Day wrote:

> 
> On Sep 28, 2008, at 3:31 PM, Paul Theodoropoulos wrote:
> > seven weeks now.
> >
> > seriously, if you found you were wrong about this issue, then a  
> > responsible investigator reports back that the original claim was  
> > erroneous - rather than leaving it hanging there like a fart in a  
> > warm room.  if you're still working on it, then "we're still working  
> > on it" is appropriate, since 'soon' long ago lapsed.
> >
> > either there's an issue - serious or not - or there is no issue. it  
> > becomes FUD when a definitive statement is never forthcoming - seven  
> > weeks is certainly not within any reasonable definition of "soon".
> 
> 
> Sorry for the delay, I've had a whole heck of a lot going on.
> 
> I'm trying to be as responsible as I can here. There is a real, but  
> not earth-shattering problem with djbdns with regard to spoofing. The  
> same type of issue may also be present in another DNS package, but  
> it's proving to be considerably harder to quantify and isolate, so I  
> want to do the right thing and not say "This problem exists in djbdns"  
> and have someone 5 minutes later realize it's also in product X where  
> it's potentially worse.
> 
> I am still working on all of this though, with some gracious help from  
> a few people with far more mathematical skills than I have to exactly  
> quantify the risk and correctness of a fix. We all believe that  
> releasing a document that accurately describes the problem in ways I  
> can't would be far better for everyone than to just release a diff and  
> try to explain why it may help.
> 
> 
> That said, I will make every attempt to expedite this, since I know  
> you guys are waiting.
> 
> -- Kevin
> 
> 
> 

-- 
Av8 Internet   Prepared to pay a premium for better service?
www.av8.net         faster, more reliable, better service
617 344 9000