Re: 2 forwarded messages...DNSEXT discussion of Day and Kaminsky

Dean Anderson <[email protected]> wrote:
> On Wed, 18 Feb 2009, Paul Jarc wrote:
>> I don't think this attack works any better against a qmerge-patched
>> dnscache.  Although dnscache forgets about its previous outgoing
>> queries, the kernel doesn't know that it has forgotten.  There's no
>> external evidence that would show up in the attacker's probe.
>
> Your analysis is incorrect:
>
> 1. The state of the kernel is indeed affected by the rate of ports being
> consumed and returned. (previously explained)

If by "the state of the kernel" you mean the kernel's entropy pool,
then we agree, but I don't see how that relates to what I said above.
If you mean that the kernel will handle an incoming response
differently based on whether dnscache has forgotten the outgoing
query, then that would be relevant, but I disagree.  I don't think
you've given any explanation of how that could be.

> The fewer ports (a single port) might be easier to discover and
> identify.  (previously explained)

You haven't explained how to distinguish recently-forgotten ports from
still-waiting-for-response ports.  With the attack I described, making
that distinction is necessary if you want to reduce the number of
ports to consider.

> 3. The number of queries sent to an authority server are affected by the
> qmerge changes. (previously explained)
>
> 4. The number of responses returned by authorities servers are affected
> by the qmerge changes. (previously explained)

Yes, that much is clear.  But are you saying that affects the attack I
described?  I don't see how.

Your statements are all very general, making it difficult to tell what
attack you're talking about from one sentence to the next.  Can you
give a clear algorithm for one single attack, and show in detail how
that attack is more effective against a qmerge-patched dnscache than
an unpatched one?

> to solve a virtually NON-existant problem.

I don't think there's any disagreement about the scope of the problem.
Anyone who's in a position to be affected by it would probably be able
to detect and stop an attack.  Some might not.  Regardless, there's no
reason not to fix the problem, if the solution doesn't introduce new
problems.

> What do you think the smart thing to do is?

So far, I haven't seen any reason not to apply the qmerge patch.

> What matters is that Kaminsky didn't discover anything about DNS on
> which to hang his name.

It's an enormous jump from there to saying that Kaminsky is malicious,
and anything produced by him or anyone who works with him can never be
trusted.


paul