Date: Wed, 25 Jul 2001 19:04:54 -0500 (CDT) From: Mike Silbersack <silby@silby.com> To: Barney Wolff <barney@databus.com> Cc: <arch@FreeBSD.ORG>, <net@FreeBSD.ORG> Subject: Re: TCP sequence numbers: RFC1948 patch ready for testing Message-ID: <20010725185434.V35719-100000@achilles.silby.com> In-Reply-To: <20010725032805.A21133@tp.databus.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, 25 Jul 2001, Barney Wolff wrote: > I have a few comments :) > > 1. Rekeying is completely unnecessary - talking of brute-forcing > the MD5 of a 32-byte random secret is fantasy, for the forseeable future. > Similarly, isn_offset adds nothing real to security. > > 2. By rekeying you risk violating the monotonicity of the isn across > the rekeying, which is the whole point of not just doing random isn. I'll go ahead and remove the isn_offset addition. I'm not really willing to remove the rekeying, though; we can't say that a faster method of brute force attack will not arise. Would a longer rekeying interval such as a day or two suffice? I'm not concerned about rekeying breaking a few connections given that it will only happen occasionally. > 3. Unless I'm confused, hz is typically 100 or 1000, meaning that the > signed-32 tick counters you're relying on to trigger rekeying will > flip sign and overflow within the typical uptime of a server. You > risk having the test fail for a long time, if isn_reseed_time is a > large positive and ticks has become negative before you get to test it. > Of course that's no loss, imo. Doh! I'll fix that in the next rev of the patch. > 4. As a nit, if you're going to do the rekeying check, do it only when > you're actually going to do the md5 work, not before the test that > may return arc4random. Will do as well. > 5. You seem to have ignored 1948's advice to include some configurable > secret in the hash - are we really sure that read_random gives good > bits right after reboot? I didn't think second-guessing the random dev would be a worthwhile endeavor, as it would probably just lead to less entropy. (Especially given that noone would ever set the configureable secret.) However, boot time randomness is a valid concern. We're slightly lucky in that the initial keying doesn't occur until the first connection, which isn't at a fixed time in the kernel startup, but is rather dependant on usage of the box. I'll check with Mark Murray on this. (And in 4.x, I'll use read_random_unlimited so that the entropy doesn't get truncated.) Thanks for the comments, Mike "Silby" Silbersack > > Regards, > Barney Wolff > > On Tue, Jul 24, 2001 at 11:19:57PM -0500, Mike Silbersack wrote: > > > > Hello all, the RFC1948-like sequence number generation patch is ready for > > testing. The patch included will apply cleanly to both a recent -current > > and a recent -stable. I've spent a good deal of time looking at tcpdump > > logs, and it looks good to me. > > > > Please test and review this if you feel comfortable doing so. If you do > > not feel comfortable doing so, please simply test it instead. :) > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20010725185434.V35719-100000>