BIND's vulnerability to packet forgery

[Jim Reid]

>>>>> "djb" == D J Bernstein <75628121832146-bind at sublist.cr.yp.to> writes:

    djb> BIND company employee Jim Reid writes:
    >> The "packet forgery" you refer to applies to verifying and
    >> signing DNS data with DNSSEC.

    djb> Wrong. As discussed in http://cr.yp.to/djbdns/forgery.html,
    djb> the current reality is that DNSSEC does nothing to prevent
    djb> forgeries.

Really? When were RSA and DSA broken?

    djb> I'm talking about the protections that _do_ stop
    djb> some attacks right now:

    djb>  (1) cryptographic randomization of DNS query IDs and 
    djb>  (2) cryptographic randomization of the UDP port for each query.

And neither of these things is a significant improvement. They barely
raise the barrier for an attacker. Both the port number and query id
are known when the query leaves the server, so responding with a fake
reply is trivial. Or don't you classify that fake reply as "forgery"?

    djb> Apparently BIND doesn't do #1 without /dev/random, 

Wrong. From setup_lookup():

	lookup->sendmsg->id = (unsigned short)(random() & 0xFFFF);

Last time I looked random() was not the same as /dev/random. Now some
might argue that random() isn't random enough. Even so it's probably
good enough as an entropy source for the purpose it gets used for
here.

    djb> and it doesn't do #2 at all. In contrast, djbdns does both #1
and #2
    djb> automatically.

So what? Randomising the port number for each query achieves precisely
nothing. Apart from making the OS and name server do more work by
explicitly naming that socket; an extra system call per query. An
attacker can still see that query in all its glory and fake a reply to
it.
    >> The reason for the irony is that your DNS software doesn't
    >> support DNSSEC or Secure Dynamic Update at all.

    djb> My software supports secure outage-free upates. Security is
    djb> provided by standard external tools, typically IPSEC or ssh.

Perhaps: for your definition of security. How does your code detect a
forged or tampered reply? Well if the reply was signed and your code
supported DNSSEC, it could do that. But it doesn't. So it can't.