From owner-freebsd-net Wed Jul 25 17: 5: 9 2001 Delivered-To: freebsd-net@freebsd.org Received: from silby.com (cb34181-a.mdsn1.wi.home.com [24.14.173.39]) by hub.freebsd.org (Postfix) with ESMTP id 1AC2C37B403 for ; Wed, 25 Jul 2001 17:04:55 -0700 (PDT) (envelope-from silby@silby.com) Received: (qmail 35910 invoked by uid 1000); 26 Jul 2001 00:04:54 -0000 Received: from localhost (sendmail-bs@127.0.0.1) by localhost with SMTP; 26 Jul 2001 00:04:54 -0000 Date: Wed, 25 Jul 2001 19:04:54 -0500 (CDT) From: Mike Silbersack To: Barney Wolff Cc: , Subject: Re: TCP sequence numbers: RFC1948 patch ready for testing In-Reply-To: <20010725032805.A21133@tp.databus.com> Message-ID: <20010725185434.V35719-100000@achilles.silby.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org 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