Re: How do we get the whole world to upgrade to DNSSEC capable resolvers?

[David Conrad <[e-mail]>]

Jesper,

On Aug 11, 2008, at 2:47 PM, Jesper G. Høy wrote:
> 4 billion packets may not be enough - we need a longer transaction ID.

Or, we could remove the vulnerability by protecting the data, not the  
transport.

> <quote>
> The core problem with the Kaminsky bug, and other cache poisoning  
> scenarios,
> is the short 16 bit transaction ID.

No.  The core problem with the Kaminsky bug is the fact that DNS data  
is unprotected during transport.  Making the transaction ID bigger  
reduces the chance of an blind insertion spoof attack, but does  
nothing for an interception spoof attack where the attacker is in the  
DNS data path.  Your XTID proposal is one of a class that treats the  
symptoms, not the underlying disease.  DNSSEC is one of a class that  
treats the disease.  In a DNSSEC-enabled world, it wouldn't matter  
where you got the response from or what zombie-laden networks the  
response traversed, you would be able to validate the response hadn't  
been tampered with.

That isn't to say that I don't think XTID et al shouldn't be  
considered and even implemented if they improve the status quo, but it  
solves a subset of the problems DNSSEC solves and as such, one has to  
consider whether it is superfluous, particularly as XTID (appears to)  
require a redeployment of both authoritative and caching servers, just  
like DNSSEC (and if you're going to redeploy, you're probably going to  
be redeploying something that is DNSSEC-capable).

> But DNSSEC was not invented to fix the Kaminsky bug (the topic of this
> thread).

Actually, it was.  Not the Kaminsky bug specifically of course, but  
the entire class of bugs that revolve around modifying DNS data in  
transit.

> I do think it is fair to ask that other possibilities at least be  
> considered
> before applying something as complex as DNSSEC to this fairly simple  
> problem
> (short transaction ID).

First, I am unaware of anyone even suggesting that other possibilities  
not be considered.  On the contrary, I seem to recall pretty much  
everyone clamoring for an alternative that provides the same level of  
protection as DNSSEC albeit with less  
{development,operational,infrastructure} cost.

Second, the problem isn't that the transaction ID is too short.  The  
short transaction ID exacerbates the problem by allowing remote  
insertion spoofing particularly when additional section processing  
comes into play.  The real problem is that the DNS protocol was  
developed during a time when "be liberal in what you accept" was a  
good idea and when nobody would intentionally muck up network data for  
illicit gain.  Times have changed.

Regards,
-drc


--
to unsubscribe send a message to [e-mail] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/namedroppers/>