Date: Fri, 02 Nov 2007 15:57:33 +0100
From: Shane Kerr <Shane_Kerr@....org>
To: Tim <tim-security@...tinelchicken.org>
Cc: bugtraq@...urityfocus.com
Subject: Re: Comments re ISC's announcement on bind9 security

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Tim,

Tim wrote:
> Hello Shane,
> 
> Thanks for your response, it was informative.
> 
>> Yes, ISC has finally gotten around to randomizing the source ports, as of
>> 9.5.0a2. It is controlled by the "use-queryport-pool" option in the server
>> section of the BIND configuration file. It defaults to "yes".
>>
>> You can control how big the pool is with the "queryport-pool-ports" option. It
>> defaults to 8 (an extra 3 bits of entropy).
>>
>> This set of ports is refreshed periodically, with a frequency controlled by the
>> "queryport-pool-updateinterval" option. (Personally I think this option adds no
>> little value from a security point of view, but it doesn't hurt.)
> 
> I see.  Well, I guess it is a step forward, though based on the somewhat
> vague description of how it works[1], it probably doesn't add much security
> as implemented.  Obviously 3 bits isn't much and you're reusing ports
> for a rather long period of time.  Given that your default refresh is
> 15min, I'm willing to bet that doing a refresh every few seconds is
> going to cause performance issues?

It shouldn't cause any performance issues to do a refresh every few seconds,
although I would think you'd be better off simply using a larger pool. I haven't
tested it, but you should be able to set the pool size to 16384 for that magical
30 bits of entropy you want (you probably want to set the refresh to a very
large value in this case).

> Other resolvers use cryptographically random IDs *and* source ports for
> every query, which brings you up to around 30bits of entropy, depending
> on the assumptions you make about allocated ports. This makes blind
> attacks much, much more difficult than just 16bits.  This isn't a new
> thing.  These ideas were implemented at least 6 years ago.  If the ISC
> was really concerned about protecting the public from these attacks,
> they've had ample time to do something about it.
> 
> Perhaps it's more politically convenient to leave blind attacks in place
> in order to push other agenda?  It seems invariably those making the
> all-or-nothing argument that 16 bits (in reality 30 bits if you get off
> your ass and think about it) is not enough entropy no matter the
> generator are all too often pushing DNSSEC in the very next sentence.
> I'm not saying DNSSEC is good or bad, and it is designed to remedy more
> than just blind attacks, but it's unethical to ignore a problem that can
> be mitigated in the short term just so a new technology can be forced
> down people's throats in the long term.

As far as I know there is no such conspiracy at ISC.

I've only been here 18 months or so, and in that time the focus has been
primarily on addressing the weaker parts of the software (recently performance,
scaling, statistics, and the like). BIND 9's security has been pretty good, so
it has not been a major concern.

> PS- My do not mean to flame you personally Shane.  My frustration is
>     directed at the ISC generally.

I'm sorry you're frustrated. There are a lot of ways you can change the
direction of ISC development. Firstly, you can submit source code - we like that
one especially. Secondly, you can fund development, and have us develop code
that you need or want done. Thirdly, you can join the BIND Forum and give us
recommendations and feedback there. Or forth, you can simply ask us.

Don't worry, I don't take it personally. I've been working in technology enough
to know that people tend to flame first, and ask questions later. I don't like
it, and I wish it wasn't part of the techy culture, but there it is.

- --
Shane
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFHKzrZMsfZxBO4kbQRApGMAJ9w9NXsPcYYgtovC2oN3nKzwuoaEwCgwl8A
uA3cKKu8I3b8k3RWbnhQQj0=
=f/6g
-----END PGP SIGNATURE-----

Powered by blists - more mailing lists