-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Sir or Madam,
I found this ISC announcement quite amusing:
http://www.isc.org/index.pl?/sw/bind/docs/response_transaction_id_issues.php
It's a text published by ISC as a follow up to the bind9 predictable id saga.
Particularly the following statement is funny, and shows complete lack
of understanding of the terminology and of the problem space:
'ISC would like to assure the Internet community that this is much
less an issue of using "extremely weak crypto" as it has been
described, than the use of a random number generator that did not
provide sufficient randomness.'
My understanding is that they used a pseudo random number generator in
bind9, and when you use a pseudo random number generator (whose
sequence in this case is predictable after observing about a dozen
outputs) instead of a strong cryptographic algorithm whose sequence
cannot be practically predictable, how do you call this? right -
"extremely weak crypto".
There seem to be two ideas you are presenting here, both intended to imply that
the developers at ISC are technically incompetent:
1. Using a pseudo-random number generator should be called "crypto".
2. The particular pseudo-random number generator that BIND 9 now uses is a poor
choice.
I think the first issue is not as important as the second issue, because it is
mostly a semantic debate. My own take on it is that "crypto" implies that
information is hidden in some way. Not all security-related technology is
cryptography. For instance, putting per-user limits on resources prevents
certain kinds of denial-of-service attacks, but it is certainly not "crypto".
Because a lot of techniques in cryptography require good random numbers, it has
been widely studied by cryptographers. Therefore if you want a good
pseudo-random number generator, it is probably a good idea to see what the state
of the art in the cryptography field is. But random number generation is not
"crypto" any more than using a series of bit shift and XOR operations is crypto.
The second issue is much more important.
Let me begin by saying that as far as I or anyone else at ISC knows, the current
BIND 9 implementation does not have any exploitable weakness in the transaction
identifier generation. If you or anyone knows otherwise, please let us know and
we'll look into it.
Having said that, the history of this exploit from our side goes something like
this:
- - Amit Klein sent us a draft document about a weakness in the linear shift
register (LSR) generator used in BIND 9.
- - A few of us had a look, and sure enough, the LSR was badly broken for this
purpose.
- - After some discussion, we opted to forward port the BIND 8 code rather than
invent a new solution to the problem.
- - Shortly after, Amit Klein sent us a draft document about a much, much worse
weakness in the BIND 8 code, which was now in BIND 9. He noted that BIND 9 did
not seem to be exploitable, but maybe theoretically it was.
- - We looked at this, and sure enough, BIND 8's query ID generator was badly
broken.
- - Since BIND 8 was almost at end of life (it is now), we opted to remove the
generator code and require a strong random number generator for this. AIUI,
the arc4random() function *has* been developed by security experts, including
cryptographers, so it should be Good Enough(tm) for a 16-bit value in software
that nobody should use.
- - Since there was no known exploit for the BIND 9 code, we decided to leave
the
code alone, with the idea to put something harder to predict at a later time.
So, I think our main mistake here was using the BIND 8 code rather than
developing a solution that was easier to understand (and analyze), based on best
current practices from pseudo-random number generators. But, since the code is
sound, I think we are on solid ground with the public statement we made.
The irony is that statement is found in a text intended to instill
trust and reassure the bind9 users that ISC digs security...
We do "dig" security. I think the track record for BIND 9 shows that.
- --
Shane Kerr
ISC
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFHKIa/MsfZxBO4kbQRAj7ZAJ43nkS/zLlz8qudDlzhmUPB+mizbQCfR8EZ
v0qZqJd+COMDQ38QD/uanto=
=lO6c
-----END PGP SIGNATURE-----
